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

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 1 11:25:05 PST 2019

-----Original Message----- From: Tim Northover <t.p.northover at gmail.com> Sent: Friday, February 1, 2019 2:28 AM To: Eli Friedman <efriedma at quicinc.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [EXT] [llvm-dev] [RFC] arm6432: upstreaming ILP32 support for AArch64

> > Second is the intrusiveness. On the plus side it's less intrusive than > > ISD::GEP would be, but it still involves changes in some fairly > > obscure bits of DAG -- often found when things broke rather than by > > careful planning. > > Did you consider modeling this with address spaces? LLVM already has robust support for address spaces with different pointer sizes, I have to say I didn't, but I don't think it would solve the problem. 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.

I don't know that this ends up being easier to implement overall, but the model is closer to what the hardware actually supports, and it involves fewer changes to target-independent code.

-Eli

More information about the llvm-dev mailing list