[llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64 (original) (raw)

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 1 12:00:15 PST 2019

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.

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.

I do like LLVM passes as a solution for most problems, and it ought to give a big head start to GlobalISel implementation too. I'll definitely give it a go as an alternative next week.

Cheers.

Tim.

More information about the llvm-dev mailing list