www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Fixing the -march/-mcpu situation

reply David Nadlinger <code klickverbot.at> writes:
Currently, -march/-mcpu are pretty much broken in LDC. [1] The cause
for the confusion is that the internal LLVM tools (llc, =E2=80=A6, includin=
g
LDC) interpret the options differently from GCC (and Clang):

For LLVM, -march selects the target architecture, i.e. x86, ARM, and
so on, and -mcpu selects specific CPUs (-mcpu=3Dcorei7) or features
(-mcpu=3D+sse42).

For GCC (which doesn't support multiple targets at the same time), on
the other hand, behavior slightly differs between the available
targets. In all cases, -march selects some sort of sub-target to use
for the compilation. For x86, these are the different instruction set
extensions/scheduling parameters (e.g. -march=3Dcorei7), where, quoting
gcc(1), =C2=BBIn contrast to -mtune=3Dcpu-type, which merely tunes the
generated code for the specified cpu-type, -march=3Dcpu-type allows GCC
to generate code that may not run at all on processors other than the
one indicated.=C2=AB. As far as GCC targeting x86 is concerned, -mcpu is a
deprecated synonym for -mtune, but for other targets, it actually
changes the permissible instructions too (which is probably why it was
deprecated on x86).

So, what should we do for LDC?
 (1) Follow the convention of the LLVM tools, because it seems like
the natural thing to do and the LLVM convention is arguably saner?
 (2) Change the meaning of the parameters to match GCC, because this
is what many users will probably expect?

If we go with (1), the flag to use for best-effort compilation would
probably be "-mcpu=3Dnative", although we could probably include
"-march=3Dnative" to provide a "just works" experience for GCC users.

In my opinion, fixing that situation is the single most important
issue to attack before pushing out a release (I've somewhat given up
on that AA issue[2] by now, I'm just not seeing the forest for the
trees). The main reason for that, besides the embarrassing fact that I
announced something in the last release notes that does not actually
work, is that people are often using LDC specifically for performance,
and extended instruction sets can make quite the difference here. Our
0.11.0 release was a step backwards for many people in that regard, as
we were always targeting the build host CPU before that (now, a
generic lowest-denominator CPU is assumed, just as most other
compilers do).

David


[1] https://github.com/ldc-developers/ldc/issues/414
[2] https://github.com/ldc-developers/ldc/issues/407
Oct 02 2013
parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Wednesday, 2 October 2013 at 17:01:41 UTC, David Nadlinger 
wrote:

 So, what should we do for LDC?
  (1) Follow the convention of the LLVM tools, because it seems 
 like
 the natural thing to do and the LLVM convention is arguably 
 saner?
  (2) Change the meaning of the parameters to match GCC, because 
 this is what many users will probably expect?

 If we go with (1), the flag to use for best-effort compilation 
 would probably be "-mcpu=native", although we could probably 
 include
 "-march=native" to provide a "just works" experience for GCC 
 users.


IMHO you should go with (1).
Real confusion will come from one LLVM tool having a different 
convention then the other LLVM tools.
Adjustment is required for going between GCC and LLVM tools 
everywhere else.

As for "-march=native" convenience option, only do so if you're 
confident it will not conflict and need to be changed later on.

If translation from GCC options to LLVM options is really needed, 
then there should be a wrapper like ldmd2 which does so.
Oct 02 2013
parent reply David Nadlinger <code klickverbot.at> writes:
On Wed, Oct 2, 2013 at 8:35 PM, safety0ff <safety0ff.dev gmail.com> wrote:

 Real confusion will come from one LLVM tool having a different convention
 then the other LLVM tools.


True, I agree. But the thing that makes the right interpretation of
this statement less obvious to me is that most people using LLVM are
probably just doing so through Clang or another LLVM-based compiler,
while the LLVM tools like llc, opt and so on are strictly compiler
developer oriented.


 Adjustment is required for going between GCC and LLVM tools everywhere el=


se.

Again, not as far as Clang is concerned, and I'm not sure how people
who haven't messed around with the internals of an LLVM-based compiler
themselves will see that.

But I suppose the most reasonable choice is indeed to go with the LLVM
tool naming scheme (which we already do now), as we differ from other
compilers based on LLVM in that we also offer all the internal
options. So, (1) would indeed be the most consistent way of handling
things.

Now I just have to figure out what the reason for having the =C2=BByou must
specify a target triple as well with -mtriple when using the -arch
option=C2=AB was. Or just remove it, as it really doesn't seem to make a
lot of sense.

David
Oct 03 2013
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Thursday, 3 October 2013 at 22:39:55 UTC, David Nadlinger 
wrote:

 But I suppose the most reasonable choice is indeed to go with 
 the LLVM
 tool naming scheme (which we already do now), as we differ from 
 other
 compilers based on LLVM in that we also offer all the internal
 options. So, (1) would indeed be the most consistent way of 
 handling
 things.


+1


 Now I just have to figure out what the reason for having the 
 »you must
 specify a target triple as well with -mtriple when using the 
 -arch
 option« was. Or just remove it, as it really doesn't seem to 
 make a
 lot of sense.


If you find the sense of that, please post it!
--
Paolo Invernizzi
Oct 04 2013
parent David Nadlinger <code klickverbot.at> writes:
On Fri, Oct 4, 2013 at 9:55 AM, Paolo Invernizzi
<paolo.invernizzi gmail.com> wrote:

 On Thursday, 3 October 2013 at 22:39:55 UTC, David Nadlinger wrote:

 But I suppose the most reasonable choice is indeed to go with the LLVM
 tool naming scheme (which we already do now), as we differ from other
 compilers based on LLVM in that we also offer all the internal
 options. So, (1) would indeed be the most consistent way of handling
 things.


 +1


The old new behavior has landed in Git master.


 Now I just have to figure out what the reason for having the =C2=BByou m=




ust

 specify a target triple as well with -mtriple when using the -arch
 option=C2=AB was. Or just remove it, as it really doesn't seem to make a
 lot of sense.



 If you find the sense of that, please post it!


Still no idea, though.

David
Oct 06 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 3 October 2013 at 22:39:55 UTC, David Nadlinger 
wrote:

 True, I agree. But the thing that makes the right 
 interpretation of
 this statement less obvious to me is that most people using 
 LLVM are
 probably just doing so through Clang or another LLVM-based 
 compiler,
 while the LLVM tools like llc, opt and so on are strictly 
 compiler
 developer oriented.


I use llmv-link & opt & llc for whole program optimization. Dunno 
if it works, but I hope so.
Oct 31 2013
parent David Nadlinger <code klickverbot.at> writes:
On Fri, Nov 1, 2013 at 7:16 AM, Kagamin <spam here.lot> wrote:

 I use llmv-link & opt & llc for whole program optimization. Dunno if it
 works, but I hope so.


It works right now, and we will try to keep it working in the future.

What I wanted to highlight is that most C/C++ developers "using LLVM"
(Clang) will hardly ever invoke the tools directly, and thus are
probably not familiar with the command line conventions for these
tools.

David
Nov 09 2013