[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:57:34 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 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.
- 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 ]