[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