This is an archive of the discontinued LLVM Phabricator instance.

[clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target
ClosedPublic

Authored by arphaman on Apr 19 2021, 6:23 PM.

Details

Summary

Clang's driver currently prints out different default triples when it's invoked like this on Apple Silicon:

$ clang --version
Target: arm64-apple-darwin19.0.0
$ clang -arch arm64 --version
Target: aarch64-apple-darwin19.0.0

This change ensures that the driver uses the canonical arch names for a Darwin triple when the target triple is being printed out by the driver.

Diff Detail

Event Timeline

arphaman created this revision.Apr 19 2021, 6:23 PM
arphaman requested review of this revision.Apr 19 2021, 6:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 19 2021, 6:23 PM
ab added a comment.Apr 20 2021, 12:33 PM

This sounds nice! One idea, maybe more dangerous, not sure which is better: in setTripleTypeForMachOArchName, we already have a couple setArchName calls, I think that's why arm64e is left alone in the aarch64-cpus.c test. Maybe we can do the setArchName call for every arch there?

Another question, probably a completely separate problem: why is it still reporting darwin? Ideally we'd want it to report macos, right? With that + your change the triple there would be the actual triple we use to build. (but maybe the macos bit only comes later when we pick up an SDK in DarwinClang or whatever?)

arphaman updated this revision to Diff 339027.Apr 20 2021, 4:11 PM

Updated with Ahmed's suggestion.

In D100807#2702675, @ab wrote:

This sounds nice! One idea, maybe more dangerous, not sure which is better: in setTripleTypeForMachOArchName, we already have a couple setArchName calls, I think that's why arm64e is left alone in the aarch64-cpus.c test. Maybe we can do the setArchName call for every arch there?

Thanks for the suggestion! I like your idea better, so I updated the patch.

Another question, probably a completely separate problem: why is it still reporting darwin? Ideally we'd want it to report macos, right? With that + your change the triple there would be the actual triple we use to build. (but maybe the macos bit only comes later when we pick up an SDK in DarwinClang or whatever?)

I think that's the default we set in the build. I do want to get rid of the 'Darwin' triple OS and just leave it as an alias for the driver at some point in the future as I don't think it's serving a good purpose anymore, but I haven't gotten around to it. I can explore using 'macOS' triples for the build before then though.

ab accepted this revision.Apr 26 2021, 10:46 AM

Neat, thanks!

This revision is now accepted and ready to land.Apr 26 2021, 10:46 AM
thakis added a subscriber: thakis.Apr 26 2021, 1:49 PM

Looks like this breaks tests on mac/arm (by making two unexpectedly pass): http://45.33.8.238/macm1/8249/step_7.txt

Please take a look, and please revert for now if it takes a while to fix.

Looks like this breaks tests on mac/arm (by making two unexpectedly pass): http://45.33.8.238/macm1/8249/step_7.txt

Please take a look, and please revert for now if it takes a while to fix.

Thanks, I will take a look.

arphaman added a comment.EditedApr 26 2021, 2:55 PM

Looks like this breaks tests on mac/arm (by making two unexpectedly pass): http://45.33.8.238/macm1/8249/step_7.txt

Please take a look, and please revert for now if it takes a while to fix.

I will revert it now.

It appears that your bot is running on a Mac with M1 is that correct? Which OS do you have installed? Thanks

Reverted in ab0df6c0346e for now.

It appears that your bot is running on a Mac with M1 is that correct? Which OS do you have installed? Thanks

Correct, it's an M1 Mini. I had to get check-clang and check-llvm to pass on M1 (PR46647, PR46644) so it looks like nobody else is running this config (why not?). check-builtins is e.g. still failing (PR49918). Kind of on that note, the clang y'all ship with Xcode is > 5% slower than it needs to be due to you apparently building it with profiles collected on an intel machine instead of with profiles collected on an arm machine (data: https://bugs.chromium.org/p/chromium/issues/detail?id=1103322#c34 There's a prebuilt binary at http://commondatastorage.googleapis.com/chromium-browser-clang/Mac_arm64/clang-llvmorg-13-init-7296-ga749bd76-2.tgz with profiles collected on arm that is ~ 12.5% faster than Xcode's clang, see comment 29 on that same crbug).

The bot is running macOS 11.3 IIRC.

It appears that your bot is running on a Mac with M1 is that correct? Which OS do you have installed? Thanks

Correct, it's an M1 Mini. I had to get check-clang and check-llvm to pass on M1 (PR46647, PR46644) so it looks like nobody else is running this config (why not?). check-builtins is e.g. still failing (PR49918). Kind of on that note, the clang y'all ship with Xcode is > 5% slower than it needs to be due to you apparently building it with profiles collected on an intel machine instead of with profiles collected on an arm machine (data: https://bugs.chromium.org/p/chromium/issues/detail?id=1103322#c34 There's a prebuilt binary at http://commondatastorage.googleapis.com/chromium-browser-clang/Mac_arm64/clang-llvmorg-13-init-7296-ga749bd76-2.tgz with profiles collected on arm that is ~ 12.5% faster than Xcode's clang, see comment 29 on that same crbug).

The bot is running macOS 11.3 IIRC.

We have M1 CI running internally but it's post commit only right now (that's something we're hoping to change in the future), so this would've been caught in our internal CI. I didn't verify this specific patch on an M1 myself though, which is something that's probably a good idea to do going forward for driver changes. I didn't know there's another M1 bot running in the open so I will be mindful of it :)

Thanks for the pointer, I'll take a look the profile data issue, and we will work on rectifying it.

We have M1 CI running internally but it's post commit only right now

Which tests is it running?

We have M1 CI running internally but it's post commit only right now

Which tests is it running?

We run check-all for our enabled projects, so that has things like check-clang and check-llvm.

Recommitted with a fix for the M1 openMP issue:

To https://github.com/llvm/llvm-project.git

3aaac01aab2f..6b938d2ead2c  main -> main