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

[Eli Friedman via llvm-dev]

Like you say, I'm pretty sure the problems you mentioned are solvable.  And you don't actually have to solve every possible inefficiency to get a usable result; it's not the end of the world if we emit an unnecessary zero extension somewhere.

But maybe modifying the DAG to allow pointers in 64-bit registers which correspond to 32-bit values in memory isn't too horrible.  It's probably not even that much code; we don't synthesize very many pointer load/store operations in SelectionDAG.  I'm mostly worried that you'll continue to discover new issues forever because nobody else has a target that differs in that particular dimension.  Maybe we'll get ILP32 ABIs for more targets that will use this functionality in the future, though.

-Eli

> -----Original Message-----
> From: Tim Northover <t.p.northover at gmail.com>
> Sent: Wednesday, February 6, 2019 7:35 AM
> To: Eli Friedman <efriedma at quicinc.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: [EXT] Re: [llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for
> AArch64
> 
> Hi again,
> 
> On Fri, 1 Feb 2019 at 19:25, Eli Friedman <efriedma at quicinc.com> wrote:
> > 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.
> 
> I've now got something about largely working via an IR-level lowering
> pass (pushed to GitHub as
> https://github.com/TNorthover/llvm-project/tree/arm64_32-arch-pass,
> please excuse any artefacts of incompleteness). I feel like it's
> rapidly approaching an unpalatability horizon though. Most issues stem
> from the fact that not all pointers are visible or controllable in the
> IR:
> 
>   + FrameIndices: you can't change an alloca's address-space since
> it's fixed by the DataLayout. So they get through to the DAG as i32s,
> significantly complicating the Addressing-mode logic.
>   + ConstantPool accesses are automatically put into addrspace(0)
>   + BlockAddress is similar.
>   + Some intrinsics are not polymorphic on pointer type, and adapting
> those that are is messy.
>   + Returns demoted to x8-indirect are always implemented by stores in
> addrspace(0).
> 
> I don't think any of these are truly insurmountable, but they do mean
> that the backend would have to cope with both i32 and i64 pointers in
> fairly ad-hoc ways, and add a lot of complexity to the approach. I
> think it's reached the point where the added complexity in AArch64 has
> outweighed the benefits to SelectionDAG so I'm inclined to stick with
> the original approach for now.
> 
> Cheers.
> 
> Tim.