Currently, -march/-mcpu are pretty much broken in LDC. [1] The cause
for the confusion is that the internal LLVM tools (llc, …, including
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=corei7) or features
(-mcpu=+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=corei7), where, quoting gcc(1), »In contrast to -mtune=cpu-type, which merely tunes the generated code for the specified cpu-type, -march=cpu-type allows GCC to generate code that may not run at all on processors other than the one indicated.«. 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=native", although we could probably include "-march=native" 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

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.

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 else.

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 »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.

David

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

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 »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!

Still no idea, though.

David

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.

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