[LLVMdev] Troubling promotion of return value to Integer ...

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Thu May 29 10:30:45 PDT 2008


 
> On further reflection, I actually like the idea of adding 4 attributes
> better than adding knowledge of "int" into TargetData.  "int" is a C
> notion that doesn't really belong in TargetData, and it is better for
> the optimizers to have the front-end expose the implicit promotions.

This is very true and indeed applicable to this problem...
So I have to agree :)

Let me summarize what we discussed so far:

1) The return value promotion will be removed from llvm backend and 
   implemented in both front-ends (clang and llvm-gcc)

2) The promotions are only applied to the return value in the body 
   of the function. 
   Return value of function definition and declaration will not be
promoted
   
   Example for a Target with 32-bit int type:

   char foo() {
     char c = ...
     return c;
   }

   Is translated to:

   define i8 @foo() {
      ...
      %tmp = sext i8 ... to i32
      ret i32 %tmp
   }

3) Return value promotion is the default behavior, however, 
   hooks will be provided to allow the Target to disable it
   and emit diagnostics.

4) There will be 4 new function attributes:
   sign_ext_from_i8, sign_ext_from_i16
   zero_ext_from_i8, zero_ext_from_i16
   These attributes will be placed on the function CALL node by
front-end
   to inform the backend about such promotions and enable optimization
of 
   return value. This should be sufficient for direct and indirect call.
   (syntax of these attributes to be defined)

Am I capturing everything?

-Ali.






More information about the llvm-dev mailing list