[llvm-dev] difference between --target, -mcpu, -march

7,781 views
Skip to first unread message

Rail Shafigulin via llvm-dev

unread,
Mar 16, 2016, 5:53:50 PM3/16/16
to llvm-dev, cfe...@lists.llvm.org
I'm confused about the clang --target, -mcpu, -march

Can someone give a clear explanation on what is the difference between them?

Originally I thought need to specify -mcpu (which I assume means CPU) and -march but then I can't figure out how --target fits into the picture. Sometimes it tells me that -march or -mcpu options is not used. I would really appreciate any help on this.

--
Rail Shafigulin
Software Engineer
Esencia Technologies

Eric Christopher via llvm-dev

unread,
Mar 18, 2016, 3:50:13 PM3/18/16
to Rail Shafigulin, llvm-dev, cfe...@lists.llvm.org
On Wed, Mar 16, 2016 at 2:53 PM Rail Shafigulin via llvm-dev <llvm...@lists.llvm.org> wrote:
I'm confused about the clang --target, -mcpu, -march

Can someone give a clear explanation on what is the difference between them?


I can try :)
 
Originally I thought need to specify -mcpu (which I assume means CPU) and -march but then I can't figure out how --target fits into the picture. Sometimes it tells me that -march or -mcpu options is not used. I would really appreciate any help on this.


Let's say you're on an x86_64-linux-gnu machine (basically any linux machine) and you want to compile some code for a haswell specific binary, you'd use:

clang -march=haswell foo.c

Which tells clang to use the current host as the "OS" for your compile and to tell the backend to generate haswell specific code.

Let's say you instead want to compile for arm-linux-gnu (just your basic arm linux machine), you'd use:

clang -target arm-linux-gnu foo.c <some other options>

I'm glossing over this a bit because it's not relevant to what you asked, but the other options there are going to be things like a sysroot where you can get the headers and libraries for an arm-linux-gnu machine, because they're likely not installed on your x86_64-linux-gnu machine.

Now, let's say you want to target a specific arm processor as part of your cross compile, you'd do this:

clang -target arm-linux-gnu foo.c -mcpu=armv7

or you could do this:

clang -target armv7-linux-gnu foo.c

this is partially because of legacy reasons, and partially because arm is weird here. The -mcpu and -march options are very similar in clang. In general, they're setting the processor you're compiling your code to run on. (Arm is even weirder here so I'm glossing over a lot of details).

The reasons behind this are largely historical and option compatibility with gcc. If you've done cross compilation with gcc all that the --target option does in clang is select at runtime the same thing that you'd use --target for on the configure line.

Make sense?

-eric 

Rail Shafigulin via llvm-dev

unread,
Mar 18, 2016, 4:44:38 PM3/18/16
to Eric Christopher, llvm-dev, cfe...@lists.llvm.org
It somewhat makes sense. Basically one has to know very well what options to use for their specific target. It looks like at the moment there is no consistency. 

Eric Christopher via llvm-dev

unread,
Mar 18, 2016, 5:18:28 PM3/18/16
to Rail Shafigulin, llvm-dev, cfe...@lists.llvm.org
-Most- targets use -march.

-eric

Rail Shafigulin via llvm-dev

unread,
Mar 18, 2016, 7:56:16 PM3/18/16
to Eric Christopher, llvm-dev, cfe...@lists.llvm.org
-Most- targets use -march.

-eric

Do you meat that in most cases -target is used along with -march instead of -target and -mcpu?

Eric Christopher via llvm-dev

unread,
Mar 18, 2016, 8:38:53 PM3/18/16
to Rail Shafigulin, llvm-dev, cfe...@lists.llvm.org

Yes and no. By target here I just mean the architecture being targeted and that most of them use the -march option rather than -mcpu. Which makes what you said a consequence of that. :)

Bruce Hoult via llvm-dev

unread,
Mar 19, 2016, 6:54:55 AM3/19/16
to Eric Christopher, llvm-dev, Clang Dev
Would it be fair to say that an -march chooses an instruction set, while -mcpu will affect scheduling things such as how many instructions can be run in parallel and their latency etc?

I actually use -m32 or -mthumb more than anything else :-)


_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


Krzysztof Parzyszek via llvm-dev

unread,
Mar 19, 2016, 12:08:51 PM3/19/16
to Bruce Hoult, Eric Christopher, llvm-dev, Clang Dev
On 3/19/2016 5:54 AM, Bruce Hoult via llvm-dev wrote:
> Would it be fair to say that an -march chooses an instruction set, while
> -mcpu will affect scheduling things such as how many instructions can be
> run in parallel and their latency etc?

From what I remember, the meaning of march/mcpu differs between clang
and LLVM's utilities (llc, etc.) In clang, mcpu and march have a lot of
overlap in terms of usage, and it seems to differ from one target to the
next. What you say would make sense, but, for example, we have legacy
code that used -march=hexagonv5, where "hexagonv5" is actually a CPU
version, something that intuitively should belong in "mcpu". Hexagon
doesn't seem to be the only one where "march" and "mcpu" are treated
almost identically, I saw what looked like CPU names in the march string
in other toolchains as well.

The clang documentation states:

Target Selection Options
~~~~~~~~~~~~~~~~~~~~~~~~
[...]
.. option:: -arch <architecture>

Specify the architecture to build for.
[...]

.. option:: -march=<cpu>

Specify that Clang should generate code for a specific processor
family
member and later. For example, if you specify -march=i486, the
compiler is
allowed to generate instructions that are valid on i486 and later
processors,
but which may not exist on earlier ones.

mcpu is not mentioned at all.

For better or worse, clang is trying to emulate GCC's options, which
have a long history behind them. There is some general idea there, but
I think the target/processor selection scheme has evolved beyond the
point where it makes sense on all levels.

-Krzysztof


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Reply all
Reply to author
Forward
0 new messages