llvm dev - Jul 2015 - [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?

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

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Steve King
> Sent: 23 July 2015 01:45
> To: llvmdev at 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,
> -steve
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Thu, Jul 23, 2015 at 3:59 AM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
>
> 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.
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.