[aot] Support multi-target builds for Apple M1

[PENGUINLIONG]

This PR enables Taichi to be built into multi-target libraries. Recent releases of macOS supports dynamically linking against x86_64 or arm64 of the same .dylib on demand, depending on the arch of the parent process. Previously this was not possible because the CMake script forced a -march=nehalem that is not a kind of arm64; and CMAKE_OSX_ARCHITECTURES is forced arm64.

The multi-target feature is only enabled with -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64". Python builds will select one of the archs, based on the arch of the skbuild Python process.

[netlify]

✅ Deploy Preview for docsite-preview ready!

Name	Link
🔨 Latest commit	939d8f0
🔍 Latest deploy log	https://app.netlify.com/sites/docsite-preview/deploys/632556b644cb620009da5ea9
😎 Deploy Preview	https://deploy-preview-6083--docsite-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[bobcao3]

What about MoltenVK? Do we need to start building and linking to it statically?

[PENGUINLIONG]

What about MoltenVK? Do we need to start building and linking to it statically?

@bobcao3 MoltenVK in VulkanSDK is already multitargeting.

[bobcao3]

What about MoltenVK? Do we need to start building and linking to it statically?

@bobcao3 MoltenVK in VulkanSDK is already multitargeting.

What about the version from homebrew, which is the one we are using?

[PENGUINLIONG]

What about MoltenVK? Do we need to start building and linking to it statically?

@bobcao3 MoltenVK in VulkanSDK is already multitargeting.

What about the version from homebrew, which is the one we are using?

Ah, yes. Homebrew serves on a per-arch basis, and our test runs install MoltenVK from homebrew. It could be an issue if someone installed homebrew molten-vk and a x86_64 Anaconda 3 (like me). We can resolve this issue in a future PR I think. And we can then get rid of the annoying TI_LIB_DIR.

[bobcao3]

What about MoltenVK? Do we need to start building and linking to it statically?

@bobcao3 MoltenVK in VulkanSDK is already multitargeting.

What about the version from homebrew, which is the one we are using?

Ah, yes. Homebrew serves on a per-arch basis, and our test runs install MoltenVK from homebrew. It could be an issue if someone installed homebrew molten-vk and a x86_64 Anaconda 3 (like me). We can resolve this issue in a future PR I think. And we can then get rid of the annoying TI_LIB_DIR.

Currently we ship a molten dylib, so it will not work

[PENGUINLIONG]

What about MoltenVK? Do we need to start building and linking to it statically?

@bobcao3 MoltenVK in VulkanSDK is already multitargeting.

What about the version from homebrew, which is the one we are using?

Ah, yes. Homebrew serves on a per-arch basis, and our test runs install MoltenVK from homebrew. It could be an issue if someone installed homebrew molten-vk and a x86_64 Anaconda 3 (like me). We can resolve this issue in a future PR I think. And we can then get rid of the annoying TI_LIB_DIR.

Currently we ship a molten dylib, so it will not work

Shouldn't be a problem atm? As mentioned before the Python wheels are built per-arch so it won't break the existing release pipeline (as the tests do). The multi-target lib can only be built if the user explicitly specify -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" in the cmake args. We still have a buffer of time to clean things up yet I somehow prefer to keep the PRs small enough to be legible.

[ailzhang]

LGTM!