[llvm-dev] [EXT] Re: [RFC] arm64_32: upstreaming ILP32 support for AArch64
Eli Friedman via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 6 13:29:30 PST 2019
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.
> -----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
> 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
> 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
> + 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
> 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.
More information about the llvm-dev