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

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.

> On Feb 1, 2019, at 3:24 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> 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.
Oh right, you don’t have the addrspace in the input.

I have long wanted a way for targets to take over the GEP expansion which may
help you? We’ll need that for non-integral pointer support anyway.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190201/3026fbeb/attachment.html>

On Fri, 1 Feb 2019 at 20:35, Matt Arsenault <arsenm2 at gmail.com>
wrote:
> Oh right, you don’t have the addrspace in the input.
Input to what? Even if it's available it's wrong without a fixup pass.
Still, custom override for GEP as you talk about later could overcome
the problem...
> I have long wanted a way for targets to take over the GEP expansion which
may help you? We’ll need that for non-integral pointer support anyway.
It has potential. If I could override GEP generation to use i64
arithmetic followed by a trunc (and use custom load/store lowering)
then it'd be a battle between DAGCombiner trying to eliminate
redundant casts (good!), and narrowing arithmetic surrounded by casts
(bad!).

I don't know which would win right now or how we could influence that,
but I am a bit worried that the semantics of the DAG would no longer
actually represent our requirements. In a pure i64-value-pointer world
there is no question: truncating to i32 is not legitimate.

The main non-integer pointer project I'm aware of is CHERI, and for
personal reasons I'm all in favour of making its job easier. Do you
have others in mind, or any other opinions in how a target should
override GEP generation? If some particular variety of arm64_32
upstreaming could provide a stepping stone for other uses that would
be a definite argument in its favour.

Cheers.

Tim.