[llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64

[Matt Arsenault via llvm-dev]

> On Feb 1, 2019, at 3:00 PM, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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 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 point, since the cast from 32 bits to 64 bits is explicitly represented, we can optimize it in the DAG or IR. For example, we can transform a load of an inbounds gep in addrspace 0 into to a load of an inbounds gep in addrspace 1.
> 
> That would have to be an IR-level pass I think; otherwise the default
> MVT for any J. Random Pointer Value is still i32, leading to the same
> efficiency issues when you eventually use that on a load/store.

I don’t see why this would need to be an IR pass. There aren’t all that many places left using the default argument to the various pointer function that can mostly be fixed. iPTR is hopelessly broken on the tablegen side, but you wouldn’t get to that point with this.

> 
> With a pass, within a function you ought to be able to promote all
> uses of addrspace(0) to addrspace(1), leaving (as you say)
> addrspacecasts at opaque sources and sinks (loads, stores, args,
> return, ...). Structs containing pointers would be (very?) messy. And
> you'd probably want it earlyish to recombine things.

You can specify the ABI alignment to 8-bytes in the data layout for the 32-bit pointer for struct layout

-Matt