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

[Tim Northover via llvm-dev]

On Fri, 1 Feb 2019 at 20:08, Matt Arsenault <arsenm2 at gmail.com> wrote:
> I don’t see why this would need to be an IR pass. There aren’t all that many places left using the default argument to the various pointer function that can mostly be fixed. iPTR is hopelessly broken on the tablegen side, but you wouldn’t get to that point with this.

The difficulty I'm seeing is that we need GEP to be lowered to i64
arithmetic, but that happens in SelectionDAGBuilder before the target
has any real opportunity to override anything. Once the GEP has been
converted to DAG, the critical information is already gone and we just
have i32 ADD/MUL trees.

The two options I see for making that happen favourably are an IR pass
or deep surgery on Clang, which seems even less appealing.

> > With a pass, within a function you ought to be able to promote all
> > uses of addrspace(0) to addrspace(1), leaving (as you say)
> > addrspacecasts at opaque sources and sinks (loads, stores, args,
> > return, ...). Structs containing pointers would be (very?) messy. And
> > you'd probably want it earlyish to recombine things.
>
> You can specify the ABI alignment to 8-bytes in the data layout for the 32-bit pointer for struct layout

I was more thinking in terms of the pass converting all value
representations of pointers to addrspace(1). That means that when a
struct gets loaded or stored directly it needs to be repacked.
Completely tractable, but not pretty.

Also, we couldn't do that anyway because the ABI is now very much set
in stone (actually has been in that regard since the very first watch
came out -- we translate bitcode for armv7k to arm64_32 which is
hopelessly doomed if the DataLayouts don't match).

And thanks for the pointers on AMD; I'll take a look at those properly
and see what we can learn.

Cheers.

Tim.