[PATCH] D96915: [AArch64][GlobalISel] Emit G_ASSERT_SEXT for SExt parameters in CallLowering
Jessica Paquette via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 2 13:23:36 PDT 2021
paquette added inline comments.
================
Comment at: llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-signext.ll:59
+ ; CHECK: [[LOAD1:%[0-9]+]]:_(s32) = G_LOAD [[FRAME_INDEX1]](p0) :: (invariant load 1 from %fixed-stack.0, align 8)
+ ; CHECK: [[ASSERT_SEXT:%[0-9]+]]:_(s32) = G_ASSERT_SEXT [[LOAD1]], 1
+ ; CHECK: [[TRUNC:%[0-9]+]]:_(s1) = G_TRUNC [[ASSERT_SEXT]](s32)
----------------
kschwarz wrote:
> Sorry for the late comment, but we recently started to migrate our backend to use the `G_ASSERT_SEXT` and `G_ASSERT_ZEXT` hints and stumbled upon some strange behavior.
>
> Our target has a very similar ABI to that of aarch64 when it comes to i1/i8/i16 arguments passed on the stack: the callee may not assume the values have been extended when passed by the caller, thus needs to explicitly sign/zero extend the argument. When passed in registers, the values are extended already be the caller.
>
> I couldn't find any code in the AArch64 backend that actually makes sure that the load will be selected to the proper extending load.
>
> For the following code:
>
> ```
> define signext i8 @a([8 x i64], i8 returned signext %x) local_unnamed_addr {
> entry:
> ret i8 %x
> }
> ```
>
> GlobalISel and SelectionDAG generate different code:
>
> GlobalISel:
> ```
> _a:
> ldrb w0, [sp]
> ret
> ```
>
> SelectionDAG:
>
> ```
> _a:
> ldrsb w0, [sp]
> ret
> ```
>
> , which looks like an ABI issue to me?
>
Thanks for the heads up.
D107305 should fix this.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D96915/new/
https://reviews.llvm.org/D96915
More information about the llvm-commits
mailing list