Tim Northover via llvm-dev
2019-Feb-06 15:35 UTC
[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.
Eli Friedman via llvm-dev
2019-Feb-06 21:29 UTC
[llvm-dev] [EXT] Re: [RFC] arm64_32: upstreaming ILP32 support for AArch64
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.
Tim Northover via llvm-dev
2019-Feb-11 20:22 UTC
[llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64
On Wed, 6 Feb 2019 at 21:29, Eli Friedman <efriedma at quicinc.com> wrote:> 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.True, though they'd have to be pretty small edge cases. And the biggest job (intrinsics) might well be the most important since both NEON and prefetch tend to be used in performance-critical code.> 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.I'd actually be more worried with the pass-based version. From what I remember only the icmp and not-inbounds GEP were really surprising in the original attempt. This time around I was hitting a lot more edge-cases that need special handling, a trend that I suspect would continue. Cheers. Tim.