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

[Tim Northover via llvm-dev]

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.