search for: arm64_32

As you may have noticed, we released a 64b S4 chip that runs an ILP32 variant of the AArch64 ABI, and now we'd like to upstream that work. I've pushed preliminary patches to https://github.com/TNorthover/llvm-project/pull/1/commits (arm64_32 branch in that repo) to accompany this RFC. The changes divide fairly neatly into three categories. First, there's AArch64 ILP32 support, which should be fairly easy to adapt to the ELF (or COFF) world and be generally useful. This involved changing some generic code in ways I'll discuss b...

...ncating to i32 is not legitimate. The main non-integer pointer project I'm aware of is CHERI, and for personal reasons I'm all in favour of making its job easier. Do you have others in mind, or any other opinions in how a target should override GEP generation? If some particular variety of arm64_32 upstreaming could provide a stepping stone for other uses that would be a definite argument in its favour. Cheers. Tim.

...easier to implement overall, but the model is closer to what the hardware actually supports, and it involves fewer changes to target-independent code. I've now got something about largely working via an IR-level lowering pass (pushed to GitHub as https://github.com/TNorthover/llvm-project/tree/arm64_32-arch-pass, please excuse any artefacts of incompleteness). I feel like it's rapidly approaching an unpalatability horizon though. Most issues stem from the fact that not all pointers are visible or controllable in the IR: + FrameIndices: you can't change an alloca's address-space sin...

...when a struct gets loaded or stored directly it needs to be repacked. Completely tractable, but not pretty. Also, we couldn't do that anyway because the ABI is now very much set in stone (actually has been in that regard since the very first watch came out -- we translate bitcode for armv7k to arm64_32 which is hopelessly doomed if the DataLayouts don't match). And thanks for the pointers on AMD; I'll take a look at those properly and see what we can learn. Cheers. Tim.

> On Feb 1, 2019, at 2:25 PM, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > I was thinking of a model something like this: 32-bit pointers are addrspace 0, 64-bit pointers are addrspace 1. ISD::LOAD/STORE in addrspace 0 are not legal: they're custom-lowered to operations in addrspace 1. (An addrspacecast from 0 to 1 is just zero-extension.) At that

...platform [2 x i32] and i64 have different alignment requirements on the stack; [2 x i32] would be used for struct { int32_t val[2]; }, i64 would be used for struct { int64_t val; }. But because AArch64 AAPCS puts more data in registers, some of these args generated for the stack go in registers on arm64_32. Cheers. Tim.

On Fri, 1 Feb 2019 at 19:25, Eli Friedman <efriedma at quicinc.com> wrote: > > Alternate address-spaces still have just one pointer size per space as > > far as I'm aware. If that's 64-bits we get efficient CodeGen but > > loading or storing a pointer clobbers more data than it should, if > > that's 32-bits then we get poor CodeGen. > > I was

...-B1SaOb/view?usp=sharing <https://drive.google.com/file/d/11Ngst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> > > My ld version is: > > ➜ ld -v > @(#)PROGRAM:ld PROJECT:ld64-530 > BUILD 18:57:17 Dec 13 2019 > configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em > LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) > TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) > > Since that said it was using LTO from Xcode I thought that might b...

This is usually a problem that is not using llvm-ar. I cannot reproduce this problem with either llvm 10.0 or TOT version. Which linker version are you using? You can also try pass "-Wl,-debug_snapshot" to the command where the error produces and then locate the "*.ld-snapshot" in /tmp directory and attach that as a reproducer. Steven > On Jul 22, 2020, at 8:41 AM, Teresa

...;https://drive.google.com/file/d/11Ngst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> >> >> My ld version is: >> >> ➜ ld -v >> @(#)PROGRAM:ld PROJECT:ld64-530 >> BUILD 18:57:17 Dec 13 2019 >> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em >> LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) >> TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) >> >> Since that said it was using LTO from Xcode I thou...

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In