[llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64 (original) (raw)
Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 07:53:02 PST 2019
- Previous message: [llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64
- Next message: [llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 ptradd 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.
- Previous message: [llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64
- Next message: [llvm-dev] [RFC] arm64_32: upstreaming ILP32 support for AArch64
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]