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

> 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 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.
+1

This is basically what we do for one address space on AMDGPU

-Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190201/9015f006/attachment.html>

On Fri, 1 Feb 2019 at 19:35, Matt Arsenault <arsenm2 at gmail.com>
wrote:
> This is basically what we do for one address space on AMDGPU
Don't suppose you could tell me which it is? No worries if you don't
remember, but it might save me a few minutes in unfamiliar code if you
do.

Cheers.

Tim.

> On Feb 1, 2019, at 3:01 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> On Fri, 1 Feb 2019 at 19:35, Matt Arsenault <arsenm2 at gmail.com>
wrote:
>> This is basically what we do for one address space on AMDGPU
> 
> Don't suppose you could tell me which it is? No worries if you
don't
> remember, but it might save me a few minutes in unfamiliar code if you
> do.
> 
> Cheers.
> 
> Tim.
The current implementation is not what it should be, since it’s currently done
in the selector (see Expand32BitAddress) for CONSTANT_ADDRESS_32BIT, which just
needs a zext to CONSTANT_ADDRESS. I’ve been meaning to move this into the
lowering for the load

-Matt