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

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 6 07:35:10 PST 2019

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 mailing list