[llvm-commits] [patch] Expose RTLIB/float-softening to targets

Akira Hatanaka ahatanak at gmail.com
Wed Jan 9 19:59:06 PST 2013


Hi Tim,

On Tue, Jan 8, 2013 at 5:07 AM, Tim Northover <Tim.Northover at arm.com> wrote:

> Hi Renato,
>
> Thanks for your comments on this too.
>
> On Tuesday 08 Jan 2013 11:22:01 Renato Golin wrote:
> > +  return TLI.makeLibCall(DAG, GetFPLibCall(N->getValueType(0),
> > +                                           RTLIB::ADD_F32,
> > +                                           RTLIB::ADD_F64,
> > +                                           RTLIB::ADD_F80,
> > +                                           RTLIB::ADD_PPCF128),
> > +                         NVT, Ops, 2, false, N->getDebugLoc());
> >
> > Shouldn't this (and all other variations) also take into account the IEEE
> > variation of long doubles?
>
> It was an active decision not to. AArch64 will not make any use of this
> code
> so it would be truly untestable as far as I'm aware.
>
>
Doesn't aarch64 use library functions for soft-float (llc -soft-float)?

mips64/linux also treats long double as 128-bit quad precision type.
mips64-gcc calls the same software emulation library function ("__addtf3"
for add) in soft-float mode (arguments are passed in integer registers), so
probably mips64 will need to pass RTLIB::ADD_F128 here.



> > As far as I can tell (I'm not a diff engine), the main move was
> > softenSetCCOperands() and makeLibCall() going to TargetLowering. Your
> > description doesn't tell why this is necessary at all and it's hard to
> > point it out from the diff, since they're in different files and
> > everything appears different, but look similar enough.
>
> It's necessary so that the AArch64 backend can call these functions from
> ISelLowering to handle its IEEE quads.
>
> > If the move was just good, not necessary, it'd be easier to have it in
> two
> > changes: one with the real change (with a small diff) and another with
> the
> > code move (for the sake of simplicity and code organization).
>
> I think that move is the entirity of the change, there is nothing else to
> split off that I can see.
>
> Cheers.
>
> Tim.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130109/20e73219/attachment.html>


More information about the llvm-commits mailing list