This is the mail archive of the gcc@gcc.gnu.org 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


Hello.
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?)

Thanks,
Tejas

On Sun, 25 Aug 2019 at 22:17, Segher Boessenkool
<segher@kernel.crashing.org> 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]