[llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64 (original) (raw)

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 1 12:24:33 PST 2019

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.

More information about the llvm-dev mailing list