[LLVMdev] promotion of return value.

[Alireza.Moshtaghi at microchip.com]

Although ABIs define the calling convention to facilitate cross language
function call on the same target, the rules of the game for return
statement in C language is also somewhat influenced by the standard and
it requirement for integer promotion, which makes it a language issue.
(if you are interested, we can discuss this later)

So in this particular issue, there is an overlap between ABI's calling
convention and C language standard for return statement. This is not a
definitive conclusion as whether we should implement return statement by
the ABI's calling convention, or by the standard. However, if we
consider practical issues such as functions without prototype, then
using the proposed attributes makes it much easier to diagnose
discrepancies in user code than if we were to rely only on the calling
convention.

For example, if a function without prototype is called, the caller
assumes int as return value, and has no information on whether the
callee has promoted the result or it is an actual int. But if we use
these attributes, then the linker would be able to set the correct
attribute on the call node once it sees the implementation of the
callee, and later optimization on the return value promotion would be
possible.

By the way, I should refine my previous assumption...
Caller and callee may very well be compiled in the different front-ends
maybe even different languages.

Regards
Ali


> -----Original Message-----
> From: Duncan Sands [mailto:baldrick at free.fr]
> Sent: Saturday, March 14, 2009 3:19 AM
> To: llvmdev at cs.uiuc.edu
> Cc: Alireza Moshtaghi - C13012
> Subject: Re: [LLVMdev] promotion of return value.
> 
> Hi,
> 
> > What we are trying to do is to add new attributes (more maybe added
> > later):
> >
> > >   sign_ext_from_i8, sign_ext_from_i16
> > >   zero_ext_from_i8, zero_ext_from_i16
> >
> > to function definition so (assuming that both caller and callee are
> > generated in the same front-end) the caller will know if the callee
has
> > already extended the return value or not, then it can promote only
if
> > needed.
> 
> I don't understand what the point of this is.  Surely this can all be
> handled by the calling convention and the signext/zeroext attributes?
> For example, suppose a function returns a short, but on the target
that
> means being returned in an i32, with sign extension.  Then in the IR
the
> function is defined as returning an i16 with the signext attribute:
> 
>   define signext i16 @f(...
> 
> The target calling convention specifies that i16's are returned in
> i32's.  When code is generated for @f this means that you get
something
> like:
> 
>       0x2696eb8: i16,ch = ...                         <= the i16 value
>     0x2696fb0: i32 = sign_extend 0x2696eb8            <= sign extended
to
> i32
>     0x26970a8: ch = ArgFlags < >
>   0x26971a0: ch = ret 0x2696ad8, 0x2696fb0, 0x26970a8 <= here returned
> 
> Perfect!
> 
> Ciao,
> 
> Duncan.