Hello,
For a simple function taking a short and returning a short, clang
generates IR with this function signature:
define signext i16 @foo(i16 signext %x)
Some questions please:
1) For the input parameter and return value, does the target control
whether clang uses signext vs something else? If so, how does this
target query work?
2) Does the presence of the signext mean it's imperative to sign
extend, or that extension, only if needed, should be signed?
Thanks,
-steve
From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Steve King
Sent: 23 July 2015 01:45
To: llvmdev@cs.uiuc.edu
Subject: [LLVMdev] signext on function parameters and return.Hello,
For a simple function taking a short and returning a short, clang
generates IR with this function signature:define signext i16 @foo(i16 signext %x)
Some questions please:
1) For the input parameter and return value, does the target control
whether clang uses signext vs something else? If so, how does this
target query work?
Yes, the function signature in the IR is target specific since it already contains some ABI information at this point. I know Mips would use the definition above but other targets may vary.
The target hook is classifyArgumentType() and classifyReturnType() in tools/clang/lib/CodeGen/TargetInfo.cpp and returning ABIArgInfo::getExtend() causes the signext/zeroexts to be emitted appropriately for the type.
2) Does the presence of the signext mean it's imperative to sign
extend, or that extension, only if needed, should be signed?
It's an agreement between the caller and callee to ensure the value is sign-extended. The exact meaning of this is target specific but for Mips it means that the values are sign-extended to full register width. Other targets might sign-extend to the nearest legal type.
So, for Mips at least, signext on a return causes the caller to assume the value is sign-extended and causes the callee to sign-extend the value. On an argument, it's the opposite way around, the caller sign-extends the value and the callee assumes it's sign extended.
Thanks for the great help. Should these classify calls be moved down
into the ABIInfo base class? They also are not marked virtual yet
targets are expected override as needed.
They're only ever called from the virtual "computeInfo" function,
which varies non-trivially across targets. So I don't think moving
them down would really achieve much beyond introducing an extra
unnecessary virtual call.
Cheers.
Tim.