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

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Fri May 16 11:12:17 PDT 2008


 

Chris,

I did not quite understand the "The bad thing about ..." part of your
argument. I'm not sure which of the two scenarios are you comparing
(promoting in FrontEnd vs BackEnd) or (promotion to int vs i32)

 

Regardless, I agree with you and shap that promotions should take place
in the FrontEnd and this is my reason:

The standard allows calling a function without prototype and assumes
"int" return value; and I realize that this is the primary reason why
the return value is being promoted. This ties this promotion to int type
and not the size of any register in target, which in turn makes it a
language issue rather than code generation issue; hence FrontEnd must
take care of it.

 

Now for our port, things are different. In most (sane) ports, the target
provides an integer class for int... however, things are different in
our (insane) port. We only have an 8-bit data bus but we also want
16-bit int type. So this promotion will make char return values (which
are used heavily in many application in 8-bit environment) quite
inefficient. So we need a way to turn off this promotion all together
and deal with default function prototype in a different way (perhaps
issue a diagnostic ...)

 

Cheers

Ali

 

 

>The bad thing about doing this is that, on the caller side, we lose
information.  With the current approach, the caller knows that the value
is (for example) 8 >bits but sign or zero extended as appropriate.  This
allows the caller side to do optimizations based on this fact.  If all
return values were i32, we wouldn't >know that the top 24 bits were
sign/zero extended.  I think we can handle this by adding some new
attributes, but this is marginally ugly.

> 

>What do you think?

> 

>-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/6df42317/attachment.html>


More information about the llvm-dev mailing list