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

[Hal Finkel]

----- 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