Similar to how we emit G_ASSERT_ZEXT when we have CCValAssign::LocInfo::ZExt.
This will allow us to combine away some redundant sign extends.
Example: https://godbolt.org/z/cTbKvr
Paths
| Differential D96915
[AArch64][GlobalISel] Emit G_ASSERT_SEXT for SExt parameters in CallLowering ClosedPublic Authored by paquette on Feb 17 2021, 4:07 PM.
Details Summary Similar to how we emit G_ASSERT_ZEXT when we have CCValAssign::LocInfo::ZExt. This will allow us to combine away some redundant sign extends. Example: https://godbolt.org/z/cTbKvr
Diff Detail
Event TimelineHerald added subscribers: danielkiss, hiraditya, kristof.beyls, rovka. · View Herald TranscriptFeb 17 2021, 4:07 PM This revision is now accepted and ready to land.Feb 18 2021, 4:52 PM Closed by commit rG95d13c01ecba: [AArch64][GlobalISel] Emit G_ASSERT_SEXT for SExt parameters in CallLowering (authored by paquette). · Explain WhyFeb 22 2021, 10:15 AM This revision was automatically updated to reflect the committed changes. kschwarz added inline comments.
Revision Contents
Diff 325480 llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-signext.ll
llvm/test/CodeGen/AArch64/GlobalISel/call-translator-ios.ll
|
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:
GlobalISel and SelectionDAG generate different code:
GlobalISel:
SelectionDAG:
, which looks like an ABI issue to me?