This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expansion of narrowing math built-ins into power instructions

Sorry for not being clear. I am confused about some modes here. I
meant, just as we expanded fadd (which narrows down from double to
float) with add_truncdfsf3, how can I expand faddl (which narrows down
long double to float). Wouldn't I require TFmode -> SFmode as
add_trunctfsf3 just as Joseph had previously mentioned? And if yes,
the operand constraints would still be f,d and d for TF->SF or what?
Also, just as we generated fadds/xsaddsp instructions for fadd, would
I be generating the same ones for faddl and fadd/xsadddp for daddl
(long double to double) or something different? all for ISA 2.07. (for
ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
add<mode>_odd followed by conversion to narrower?)


On Sun, 25 Aug 2019 at 22:17, Segher Boessenkool
<> wrote:
> [ Please don't top-post ]
> On Sun, Aug 25, 2019 at 07:32:01PM +0530, Tejas Joshi wrote:
> > I want to extend this patch for FADDL and DADDL. What operand
> > constraints should I use for TFmode alongside "f"?
> It depends on the instruction you use, and what registers that then
> works on.  GPRs get "r", FPRs get "f" for SFmode but "d" otherwise, the
> VRs get "v", if all VSRs are allowed you get "wa".  And there are some
> mode attributes to go with mode iterators for when you handle multiple
> modes (which you always do, you need to handle KF as well).
> What machine insns do you want to generate?  There most likely is
> something a lot like it already, so take that as example?
> > > In cases where long double and double have the same mode,
> > >the daddl function should use the existing adddf3 pattern.
> Sure, that probably should be handled in generic code (not rs6000).
> Where it would generate an adddfdf2 it should just do an adddf3.
> > So, should I use adddf3 for DADDL directly? How would I map the
> > add<mode>3 optab with DADDL?
> Simply check if source and target mode are the same?
> Segher

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]