This patch adds very basic support so that Clang can recognize "-arch arm64_32", translate it to Triple::aarch64_32, and instantiate at least some kind of CodeGen classes to get IR out the other end. The output will still be incorrect after this patch.
Details
Diff Detail
Event Timeline
During upstreaming we've changed from detecting an "arm64_32" ArchName to using a Triple::aarch64_32 Arch. We recently discovered a bug that meant only AArch32 NEON types were permitted, which is fixed in this new revision.
Also, ping.
Oops, yes. I'll leave it wrong though, the best that could come out of any attempt to change it would be to split the thread on llvm-commits.
Hi Tim. Would it be possible to split this in the 'trivial' changes (extending the triple handling for example) and the arm64_32 related changes to size, ABI stuff and so on? The trivial changes look good to me and by splitting them off people can focus on reviewing the more important changes.
clang/lib/Basic/Targets/AArch64.h | ||
---|---|---|
93 | Why is this needed? It seems unused in the diff? |
Thanks for the suggestion Florian, and sorry it's taken so long to act on it. I've split the patch up as you suggest, I'll make this one cover the Triple bits.
clang/lib/Basic/Targets/AArch64.h | ||
---|---|---|
93 | It's overriding a virtual function used to decide whether __int128 is allowed, and the default implementation checks the pointer width. We're still AArch64 though so we can support __int128 just as well with 32-bit or 64-bit pointers. |
This diff now only covers the trivial additions so that "arm64_32" is understood by the driver and creates AArch64 instantiations of relevant classes. Code generated is still wildly incorrect (not even ILP32 yet).
Why is this needed? It seems unused in the diff?