Page MenuHomePhabricator

[compiler-rt][Darwin] Check for arm64 support directly
Changes PlannedPublic

Authored by smeenai on Apr 27 2022, 2:35 PM.

Details

Summary

Rather than having to manually map SDK versions to their supported
architectures, just directly ask the SDK which architectures it
supports. This detection is tweaked to use SDKSettings.json to match
Clang (https://reviews.llvm.org/D55673) and reportedly Xcode [1], which
lets us check for architecture support directly instead of relying on
string matching another command's output. I also unified the arm64
checking for all platforms.

[1] https://worthdoingbadly.com/sim-macos-arm-sdk/#what-i-learned

Diff Detail

Event Timeline

smeenai created this revision.Apr 27 2022, 2:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 27 2022, 2:35 PM
smeenai requested review of this revision.Apr 27 2022, 2:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 27 2022, 2:35 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
smeenai edited the summary of this revision. (Show Details)Apr 27 2022, 2:52 PM

It seems that codes for tvos simulator also needs to be modified.

smeenai updated this revision to Diff 425633.Apr 27 2022, 3:46 PM

Adjust tvos simulator architecture detection as well

It seems that codes for tvos simulator also needs to be modified.

Thanks, I'd missed that somehow.

delcypher added inline comments.May 2 2022, 6:57 PM
compiler-rt/cmake/builtin-config-ix.cmake
88

With this implementation we can't tell the difference between the python failing for some other reason (e.g. executable path wrong, SDK JSON file doesn't exist). Are we sure we want that?

101

Any chance you could make the interface like this?

function(darwin_add_arm64_if_supported all_possible_archs os sdk_name)
  set(sdk_path "${DARWIN_${sdk_name}_SYSROOT}")
  # Compute <COMPUTED VAR>
  # ...
  set("${all_possible_archs}" <COMPUTED VAR> PARENT_SCOPE)
endfunction()

which is then called like

darwin_add_arm64_if_supported(DARWIN_iossim_BUILTIN_ALL_POSSIBLE_ARCHS ios iphonesimulator)

The changes are basically

  • prefix with darwin because the method is actually Darwin specific.
  • Don't pass SDK path when only the SDK name is needed.
  • Use ordering of arguments that matches Apple's internal code.
delcypher added inline comments.May 2 2022, 6:59 PM
compiler-rt/cmake/builtin-config-ix.cmake
83

@arphaman Do we know when SDKSettings.json was added? If it's not present in older SDKs then we won't be able to build against them with this change.

@smeenai Thanks for the patch. I think the overall spirit of this change is good. There are just some details to work out which I've left in other comments.

delcypher added inline comments.May 3 2022, 9:57 AM
compiler-rt/cmake/builtin-config-ix.cmake
88

Sorry that should say:

With this implementation we can't tell the difference between the architecture not being supported and python failing for some other reason (e.g. executable path wrong, SDK JSON file doesn't exist).

steven_wu added inline comments.May 3 2022, 11:17 AM
compiler-rt/cmake/builtin-config-ix.cmake
83

I think 10.14 is the first version we have JSON SDKSettings.

smeenai planned changes to this revision.May 6 2022, 1:25 PM

Planning changes to remove from people's queues while I address the comments (which will take a bit, since I'm out next week). Thanks for the reviews!

compiler-rt/cmake/builtin-config-ix.cmake
83

Ah, and I assume that's new enough that we can't rely on this for compiler-rt. That's a bit of a bummer, because reading the JSON directly seemed nicer than parsing the output of another program (especially once we can use string(JSON)), but I can just change this part back (or maybe try the JSON and fall back to the plist if it's not available, but idk if that's overkill; I guess it depends on if the plist will ever go away in the future and if the JSON is considered to be more modern or canonical in any way).

101

Yup, I'm happy to make that change.

delcypher added inline comments.May 6 2022, 3:39 PM
compiler-rt/cmake/builtin-config-ix.cmake
83

Well for Apple internal builds it's fine. We don't build with SDKs that old.

For the greendragon CI (https://green.lab.llvm.org/green/) it says it's using Xcode 11.5 and that comes with the macOS 10.15.4 SDK (https://developer.apple.com/documentation/xcode-release-notes/xcode-11_5-release-notes).

So in principle I think this change "should" be fine. It might be wiser to split this change out in to a separate commit (given that it seems orthagonal) so that you can easily revert that part without needing to revert the rest of your change, just in case something goes wrong.