llvm dev - Oct 2012 - [LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values

On 22/10/12 21:12, Rafael Espíndola wrote:
> On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com>
wrote:
>> So, I'm not really sure if this is the right approach. I'd like
some
>> folks from the LLVM side of things to chime in.
>>
>> In general, I'm not certain we want to continue growing our
dependence
>> on the signext and zeroext attributes on return types, or whether we
>> want to do the extension in the frontend instead.
>>
>> Most of the targets in Clang currently eagerly zext or sext the return
>> value to make it conform to the ABI. You can look at some of the other
>> classify*Type methods in Clang for how.
>
> As far as I know the difference is enabling optimization. If we see a
>
> declare i8 zeroext @foo()
>
> the caller knows that the top bits of the return are 0. There was some
> discussion about just using the range metadata, but that is not
> available for arguments/returns at the moment.
Chris wrote some notes about this:
   http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
The plan seems sensible to me, but was blocked by not having a good
way of attaching the information to parameters and return values.
Hopefully Bill's attribute work means it is now possible.

Ciao, Duncan.

----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: "Rafael Espíndola" <rafael.espindola at gmail.com>
> Cc: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>,
"llvm cfe" <cfe-commits at cs.uiuc.edu>, "LLVM Developers
Mailing
> List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, October 23, 2012 2:13:37 AM
> Subject: Re: [LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit
function arguments / return values
> 
> On 22/10/12 21:12, Rafael Espíndola wrote:
> > On 22 October 2012 14:53, Chandler Carruth <chandlerc at
google.com>
> > wrote:
> >> So, I'm not really sure if this is the right approach. I'd
like
> >> some
> >> folks from the LLVM side of things to chime in.
> >>
> >> In general, I'm not certain we want to continue growing our
> >> dependence
> >> on the signext and zeroext attributes on return types, or whether
> >> we
> >> want to do the extension in the frontend instead.
> >>
> >> Most of the targets in Clang currently eagerly zext or sext the
> >> return
> >> value to make it conform to the ABI. You can look at some of the
> >> other
> >> classify*Type methods in Clang for how.
> >
> > As far as I know the difference is enabling optimization. If we see
> > a
> >
> > declare i8 zeroext @foo()
> >
> > the caller knows that the top bits of the return are 0. There was
> > some
> > discussion about just using the range metadata, but that is not
> > available for arguments/returns at the moment.
> 
> Chris wrote some notes about this:
>    http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
> The plan seems sensible to me, but was blocked by not having a good
> way of attaching the information to parameters and return values.
> Hopefully Bill's attribute work means it is now possible.
Indeed. Are you proposing that Ulrich hold off on the current fix in favor of
the new attribute scheme, or that he should fix this using the current mechanism
for now (perhaps with a FIXME to upgrade to the new scheme once it is in place)?
I would prefer for him to commit this now, and then upgrade later.

Thanks again,
Hal
> 
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

Hi Hal,
>> Chris wrote some notes about this:
>>     http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
>> The plan seems sensible to me, but was blocked by not having a good
>> way of attaching the information to parameters and return values.
>> Hopefully Bill's attribute work means it is now possible.
>
> Indeed. Are you proposing that Ulrich hold off on the current fix in favor
of the new attribute scheme, or that he should fix this using the current
mechanism for now (perhaps with a FIXME to upgrade to the new scheme once it is
in place)? I would prefer for him to commit this now, and then upgrade later.
I don't have anything useful to say about Ulrich's fix since I
didn't look at
it.  I just wanted to make sure that everyone knew where we are probably going:
in the direction laid out by Chris in those notes.

Ciao, Duncan.