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 <seg...@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
