clang -march=x86-64 is different from the generic x86-64 tuning

[zmodem]

I was wondering why clang seems to prefer add $1 over inc when building Chromium, even though 0b7669f made inc no longer considered slow in the generic tuning.

It seems it's because we pass -march=x86-64. Which is surprising to me, because that sounds generic enough.

Consider:

$ cat /tmp/a.cc
bool f(unsigned *i) {
      return ++(*i) == 0;
}

$ clang -O2 -S -o - /tmp/a.cc -target x86_64-unknown-linux-gnu
[...]
        incl    (%rdi)
        sete    %al
        retq

$ clang -O2 -S -o - /tmp/a.cc -target x86_64-unknown-linux-gnu -march=x86-64
[...]
        addl    $1, (%rdi)
        sete    %al
        retq

Is this working as intended?

Adding -mtune=generic brings back the inc instruction:

$ clang -O2 -S -o - /tmp/a.cc -target x86_64-unknown-linux-gnu -march=x86-64 -mtune=generic
[...]
        incl    (%rdi)
        sete    %al
        retq

[phoebewang]

This is intended. generic aims for an average of popular targets. So it will change over time. x86-64 represents a minimal feature collections, which should be only used to be compatible with very old 64 bit targets. It's recommended to try with -march=x86-64-v2 or above based on your targets. Or simply not to use -march=x86-64.

[llvmbot]

@llvm/issue-subscribers-backend-x86

[zmodem]

Thanks, I'll look into why we're passing the flag in the first place. Closing since it sounds like clang is working as intended.

(http://crbug.com/1308407 for anyone interested)