[LLVMdev] promotion of return value.

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Fri Mar 13 14:35:55 PDT 2009


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




More information about the llvm-dev mailing list