[LLVMdev] promotion of return value.

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Wed Apr 1 10:21:29 PDT 2009

Please read below:

> > ---
> > I think callers need to assume that return value is in %al and that
> > the upper bits of %eax are undefined.  If the caller needs a 32-bit
> > sign- or zero-extended value, it needs to do the extend itself.  I
> > believe GCC, ICC, and MSVC all behave this way.
> >
> > Given that, it shouldn't matter how the callee handles the upper
> > bits.  It should do whatever is most convenient.
> Exactly. Note that y returns a short, and z  wants an int. It is
> z's responsibility to do a sign extension. The example claims that a
> sign extension is not necessary.

The truth of the matter is that for our target (PIC16) none of the above is really necessary. But the existing behavior of LLVM is giving us trouble and that is why we would like to push for this change to go through. 
To me, the most troubling part is the wrong assumptions that: 
1- "int is always 32 bits" and 
2- "smaller than int return values are always returned in a 32 bit register"
If we agree that part of the solution is to allow targets to decide what is the right number of bits, then we can also agree that there are really two strategies to address this problem:
1- convention based - assume a convention for code generation that front-end and backend follow. (this is what most other compilers do)
2- attribute based - front-end explicitly define the number of bits by setting attributes so back-ends do not get confused. (this is what Chris is suggesting)

I think the second approach is less confusing and Chris is going over many reasons for this in his note. But I also would like to add another reason:
In the cases that an external function is called without a prototype, having attributes makes it much easier to disambiguate and also generate better code. In such situations the llvm linker will be able to set the right attribute on the function call when it sees the callee; and then there would be no confusion on part of code generator and optimizers. Doing such things in a convention based strategy is not so trivial.


More information about the llvm-dev mailing list