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

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.

> On Feb 1, 2019, at 3:57 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> 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.
AMDGPU basically has 128-bit fat pointers for lots of intrinsics. We currently
hack around this by using <4 x i32>, which isn’t really valid since LLVM
assumes memory access is through a pointer type. We would like to have 128-bit
fat pointers, but only the low 48-bits really behave as an integer. We want to
do 64-bit adds on the low bits, and preserve the high metadata bits.

I haven’t looked too closely at how to actually implement this, but some form of
target control of GEP lowering is definitely needed for this. I imagine this
looks something like a ptr_add instruction, and most of the GEP complexity is
turned into a simple byte offset from this.

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

On Fri, 1 Feb 2019 at 21:21, Matt Arsenault <arsenm2 at gmail.com>
wrote:
> I haven’t looked too closely at how to actually implement this, but some
form of target control of GEP lowering is definitely needed for this. I imagine
this looks something like a ptr_add instruction, and most of the GEP complexity
is turned into a simple byte offset from this.
Unfortunately, having thought some more about this approach I don't
think it'll work for arm64_32.

The barrier is that each instruction is expanded in isolation so it
has to conform to a type interface; in this case it would be that
pointer SDValues are i32. So no matter how cunning our expansion is
there would have to be a trunc/zext pair between (say) a GEP expansion
and its use in a store instruction. That's a real masking operation
and prevents the addressing-modes being used. Using trunc/anyext
instead would be foldable, but it's unsound.

If instead we went for an i64 interface, I think the result would be
pretty much equivalent to the implementation I already have (hooks on
load/store/GEP/icmp in SelectionDAGBuilder, i.e. the places where it
matters that pointers are really 32-bit).

I'm having some success with the IR-level pass though. Not finished
yet, and I have no idea how the backend will cope with the new IR, but
it's mostly transforming things as I'd expect.

Cheers.

Tim.