llvm dev - Mar 2009 - [LLVMdev] promotion of return value.

Rafael Espindola a écrit :
> My proposal is to make the extension as explicit as possible. If the
> callee is extending an char to an int, the generated llvm code should
> return an i32 and the caller can assume that the extension has been done.
>
> Are you saying that the decision to do the extension in the callee happens
> after we have generated llvm? That is, an optimization is transforming
> a function that would return an i8 into one that returns i16 or i32?
>
> Do you have a testcase for the problem you are trying to solve?
>   
I think the problem was that some target don't support i32 natively (in 
hadware) like for exemple the PIC16. To force an extension to i32 is 
expensive on these target and may pose ABI compatibility problems.

Anyways, i32 on 64 bits targets may be inefficient, so solving the 
problem in a more general way is better. Impossing i32 as *the* default 
size used by everyone is wrong.

just my 2cents

Cédric

Cedric is right,
Our target, PIC16, is 8-bit and promotion to 32-bit is really bad for us...
Now what exactly is going to happen once these attributes are added, depends on
the target.
For example, in our case, there will be no promotion on the callee side, but the
caller will decide if it wants to promote or not...
What will happen in general is that front-end (clang and llvm-gcc) will do the
promotion on return value (if so intended by the target) on the callee side, and
will set the appropriate attribute both on the call node and function
definition. Then the optimizers will also get a chance to modify these
attributes as they deem appropriate according to the particular optimizations
that they may do.
Finally, llvm codegen will use the attribute on the call node to know if there
needs to be any extension on the return value or not.

This does not bound us to any particular size promotion. The solution is generic
enough to address all possibilities (of course new attributes may be needed)

Regards
Ali
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On
> Behalf Of Cédric Venet
> Sent: Friday, March 13, 2009 1:54 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] promotion of return value.
> 
> Rafael Espindola a écrit :
> > My proposal is to make the extension as explicit as possible. If the
> > callee is extending an char to an int, the generated llvm code should
> > return an i32 and the caller can assume that the extension has been
> done.
> >
> > Are you saying that the decision to do the extension in the callee
> happens
> > after we have generated llvm? That is, an optimization is transforming
> > a function that would return an i8 into one that returns i16 or i32?
> >
> > Do you have a testcase for the problem you are trying to solve?
> >
> 
> I think the problem was that some target don't support i32 natively (in
> hadware) like for exemple the PIC16. To force an extension to i32 is
> expensive on these target and may pose ABI compatibility problems.
> 
> Anyways, i32 on 64 bits targets may be inefficient, so solving the
> problem in a more general way is better. Impossing i32 as *the* default
> size used by everyone is wrong.
> 
> just my 2cents
> 
> Cédric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> This does not bound us to any particular size promotion. The solution is
generic enough to address all possibilities (of course new attributes may be
needed)
We are both trying to do the same, I just don't see why this can't be
done completely in llvm-gcc or clang. Do you have an C example where
we
currently do sign extension and that we would be able to avoid it with
your proposal?
> Regards
> Ali

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047