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

[Eli Friedman via llvm-dev]

> -----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] arm64_32: 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