llvm dev - Mar 2009 - [LLVMdev] promotion of return value.

Rafael Espindola wrote:
>>> 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
> 
> You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779.
> 
> If I understand what you are proposing, it is exactly the opposite of
> what gcc does, which would be annoying for someone trying to link gcc
> and llvm compiled code.
That's right.  In gcc we used to do this in the front-ends but we
stopped.  This required quite a lot of discussion with the Linux ABI
standardization people.

Andrew.

On Mar 12, 2009, at 11:31 AMPDT, Andrew Haley wrote:
> Rafael Espindola wrote:
>>>> 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
>>
>> You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779
>> .
>>
>> If I understand what you are proposing, it is exactly the opposite of
>> what gcc does, which would be annoying for someone trying to link gcc
>> and llvm compiled code.
>
> That's right.  In gcc we used to do this in the front-ends but we
> stopped.  This required quite a lot of discussion with the Linux ABI
> standardization people.
Yes, I trust we're taking into account that some ABIs have  
requirements about this.
For example, ARM AAPCS requires the caller promote arguments, and the  
callee
promote return values.

What I was planning to do is to provide a default behavior that is
consistent with what currently llvm does (promote to 32 bit)
And then there will be control in clang for targets to do things
differently.
But I also understand you concern about gcc frontend; because the same
thing has to also take place there....
We had long discussions about this last year, and this is what has been
decided. Maybe Chris is in a better position to decide what to do.

A.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
On
> Behalf Of Dale Johannesen
> Sent: Thursday, March 12, 2009 11:45 AM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] promotion of return value.
> 
> 
> On Mar 12, 2009, at 11:31 AMPDT, Andrew Haley wrote:
> 
> > Rafael Espindola wrote:
> >>>> 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
> >>
> >> You might want to look at bug
http://llvm.org/bugs/show_bug.cgi?id=3779
> >> .
> >>
> >> If I understand what you are proposing, it is exactly the opposite
of
> >> what gcc does, which would be annoying for someone trying to link
gcc
> >> and llvm compiled code.
> >
> > That's right.  In gcc we used to do this in the front-ends but we
> > stopped.  This required quite a lot of discussion with the Linux ABI
> > standardization people.
> 
> Yes, I trust we're taking into account that some ABIs have
> requirements about this.
> For example, ARM AAPCS requires the caller promote arguments, and the
> callee
> promote return values.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev