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

Hi Tejas, On Mon, Sep 02, 2019 at 08:55:28AM +0530, Tejas Joshi wrote: > On Sat, 31 Aug 2019 at 02:05, Segher Boessenkool > wrote: > > > > > > > > [ Please don't top-post ] > > > > (I delete everything under your signature, without looking, assuming you > > just forgot to). > > Oh sorry, I didn'

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

On Sat, 31 Aug 2019 at 02:05, Segher Boessenkool wrote: > > > > > > [ Please don't top-post ] > > (I delete everything under your signature, without looking, assuming you > just forgot to). Oh sorry, I didn't know the reply button does evil things. :-) > If long double is double, faddl is the sa

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

> > > > [ Please don't top-post ] (I delete everything under your signature, without looking, assuming you just forgot to). On Sat, Aug 31, 2019 at 12:48:42AM +0530, Tejas Joshi wrote: > > For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware > > that is. I don't know if we'll wa

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

Hello. > For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware > that is. I don't know if we'll want fadd support in the emulation > libraries ever; don't worry about it for now, anyway. What instructions would need to be expanded for FADDL (long double to float) and DADDL (long

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

Hi, On Sat, Aug 24 2019, Richard Sandiford wrote: > Martin Jambor writes: ... >> >> 2. direct_internal_fn_supported_p on which replacement_internal_fn >>depends to expand built-ins as internal functions cannot handle >>conversion optabs... and narrowing is a kind of conversion and the >

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

> > [ Please don't top-post ] On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote: > 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 do

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 Jos

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

[ 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",

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

Hello. > > Similarly addtfsf3 that multiplies TFmode and produces an SFmode result, and > so on. I want to extend this patch for FADDL and DADDL. What operand constraints should I use for TFmode alongside "f"? > In cases where long double and double have the same mode, >the daddl function should

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

Martin Jambor writes: > Hello, > > On Thu, Aug 22 2019, Segher Boessenkool wrote: >>> > Hi Tejas, >>> > >>> > [ Please do not top-post. ] >> >> On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote: >>> > What happens then? "It does not work" is very very vague. At least it >>> > seems the

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

Hi! On Fri, Aug 23, 2019 at 07:16:59PM +0200, Martin Jambor wrote: > Therefore, at least for now (GSoC deadline is kind of looming), I > decided that the best way forward would be to not rely on internal > functions but plug into expand_builtin() and I wrote the following, > lightly tested patch -

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

Hello, On Thu, Aug 22 2019, Segher Boessenkool wrote: >> > Hi Tejas, >> > >> > [ Please do not top-post. ] > > On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote: >> > What happens then? "It does not work" is very very vague. At least it >> > seems the compiler does build now? >> >> Oh

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

> > Hi Tejas, > > > > [ Please do not top-post. ] On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote: > > What happens then? "It does not work" is very very vague. At least it > > seems the compiler does build now? > > Oh, compiler builds but instruction is still "bl fadd". It should b

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

> What happens then? "It does not work" is very very vague. At least it > seems the compiler does build now? Oh, compiler builds but instruction is still "bl fadd". It should be "fadds" right? On Thu, 22 Aug 2019 at 11:55, Segher Boessenkool wrote: > > Hi Tejas, > > [ Please do not top-post.

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

Hi Tejas, [ Please do not top-post. ] On Thu, Aug 22, 2019 at 09:09:37AM +0530, Tejas Joshi wrote: > Yes, I tried basically every combination I could think of, just not > with the "isa attr". Now, I have the following code and it is still > seems not to be working. Am I missing any options to pas

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

> This does almost exactly the same as what the proposed float_narrow > would do. Instead, write it as > > (define_insn "add_truncdfsf3" > [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa") > (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa") > (match_operand:

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

On Wed, Aug 21, 2019 at 01:28:52PM -0500, Segher Boessenkool wrote: > (define_insn "add_truncdfsf3" > [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa") > (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa") > (match_operand:DF 2 "gpc_reg_operand" ",wa")] >

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

Hi Tejas, On Wed, Aug 21, 2019 at 10:56:51PM +0530, Tejas Joshi wrote: > I have the following code which uses unspec but I am really missing > something here. Does unspec not work encapsulating plus? Or I have > some more places to make changes to? > > (define_insn "add_truncdfsf3" > [(set (mat

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

Hello. I have the following code which uses unspec but I am really missing something here. Does unspec not work encapsulating plus? Or I have some more places to make changes to? (define_insn "add_truncdfsf3" [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa") (unspec:SF [(plus:DF

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

On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote: > >> Segher Boessenkool writes: > >> >> [(set (match_operand:SI 0 "register_operand" "=d") > >> >> (truncate:SI > >> >>

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

On Tue, 20 Aug 2019, Segher Boessenkool wrote: > plus minus neg mult div mod smin smax abs sqrt fma I think? And let's > hope we never ever have to do saturating versions of FP :-) There are six operations with narrowing versions in TS 18661-1 (plus minus mult div sqrt fma). neg and abs are o

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

Richard Sandiford writes: >> And yes, it is icky. But it is sound, as far as I can see. > > I really disagree that it's sound, but no point me saying why again :-) > > (It could certainly be made to work with sufficient hacks of course, > like pretty much anything could, but I don't think that's

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

Segher Boessenkool writes: > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote: >> Segher Boessenkool writes: >> >> [(set (match_operand:SI 0 "register_operand" "=d") >> >> (truncate:SI >> >> (lshiftrt:DI >> > >> > (this is optimised to a subreg, in many cases,

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

On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > >> [(set (match_operand:SI 0 "register_operand" "=d") > >> (truncate:SI > >> (lshiftrt:DI > > > > (this is optimised to a subreg, in many cases, for example). > > Right. MIPS avoi

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

Segher Boessenkool writes: >> > And yes, various parts of GCC can manipulate RTL, doing substitution and >> > algebraic simplication and whatnot. All within the rules of RTL. And >> > that means nothing ever can "pass" a float_narrow, because there are no >> > rules that allow it to. >> >> You

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

On Tue, Aug 20, 2019 at 08:41:29AM +0100, Richard Sandiford wrote: > Tejas: given the controversy, I agree unspecs sound like a good approach > for now. We can always go back and add the rtx codes later once there's > agreement on what they should look like. Yup. > Segher Boessenkool writes: >

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

Tejas: given the controversy, I agree unspecs sound like a good approach for now. We can always go back and add the rtx codes later once there's agreement on what they should look like. Segher Boessenkool writes: > On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote: >> Tejas Joshi

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

Hi Richard, On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote: > Tejas Joshi writes: > >> It's just a different name, nothing more, nothing less. Because it is > >> a different name it can not be accidentally generated from actual > >> truncations. > > > > I have introduced float

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

> but an unspec is of course easiest for now. So, at this point, should I proceed with UNSPEC considering the complications that might arise as Richard points out? On Sat, 17 Aug 2019 at 13:51, Richard Sandiford wrote: > > Tejas Joshi writes: > > Hi, > > > >> It's just a different name, nothin

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

Tejas Joshi writes: > Hi, > >> It's just a different name, nothing more, nothing less. Because it is >> a different name it can not be accidentally generated from actual >> truncations. > > I have introduced float_narrow but I could not find appropriate places > to generate it for a call to fadd

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

Hi, > It's just a different name, nothing more, nothing less. Because it is > a different name it can not be accidentally generated from actual > truncations. I have introduced float_narrow but I could not find appropriate places to generate it for a call to fadd instead it to generate a CALL. I

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

Segher Boessenkool writes: > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: >> Tejas Joshi writes: >> > Hello. >> > I just wanted to make sure that I am looking at the correct code here. >> > Except for rtl.def where I should be introducing something like >> > float_contract (

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

On Thu, Aug 15, 2019 at 03:29:03PM +0530, Tejas Joshi wrote: > Also, in what manner should float_contract/narrow be different from > float_truncate as both are trying to do similar things? (truncation > from DF to SF) It's just a different name, nothing more, nothing less. Because it is a differe

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

On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: > Tejas Joshi writes: > > Hello. > > I just wanted to make sure that I am looking at the correct code here. > > Except for rtl.def where I should be introducing something like > > float_contract (or float_narrow?) and also simplify

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

> I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. In that case, something like FADD. But for functions like fs

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

Tejas Joshi writes: > Hello. > I just wanted to make sure that I am looking at the correct code here. > Except for rtl.def where I should be introducing something like > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > set on functions around expr.c, cfgexpand.c where I gre

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

Hello. I just wanted to make sure that I am looking at the correct code here. Except for rtl.def where I should be introducing something like float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints set on functions around expr.c, cfgexpand.c where I grep for float_truncate/FLOAT_TRUN

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

On Wed, Aug 14, 2019 at 08:23:27PM +, Joseph Myers wrote: > On Wed, 14 Aug 2019, Segher Boessenkool wrote: > > > Does something like > > float d; double a, b, x; > > ... > > d = fadd (a + x, b - x); > > work as wanted, with such a representation? It would simplify (does it?) to > > d

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

On Wed, 14 Aug 2019, Segher Boessenkool wrote: > Does something like > float d; double a, b, x; > ... > d = fadd (a + x, b - x); > work as wanted, with such a representation? It would simplify (does it?) to > d = fadd (a, b); > but is that allowed? It's not allowed, but neither is simpli

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

On Wed, Aug 14, 2019 at 04:10:56PM +, Joseph Myers wrote: > On Wed, 14 Aug 2019, Segher Boessenkool wrote: > > > I think you can do one RTL code that replaces float_truncate in > > > > > > > > (define_insn "add_truncdfsf3" > > > > > > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") > >

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

On Wed, 14 Aug 2019, Segher Boessenkool wrote: > I think you can do one RTL code that replaces float_truncate in > > > > > > (define_insn "add_truncdfsf3" > > > > > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") > > > > > (float_truncate:SF > > > > > (plus:DF (match_operand:DF 1

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

On Wed, Aug 14, 2019 at 11:51:28AM +0530, Tejas Joshi wrote: > > The RTL needs to be something that > > does *not* match the combination of separate operations (just as fma has > > its own RTL, and a separate pass is responsible for converting separate > > So do I need to introduce fadd's own RTL

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

> The RTL needs to be something that > does *not* match the combination of separate operations (just as fma has > its own RTL, and a separate pass is responsible for converting separate So do I need to introduce fadd's own RTL just as fma which would emit a fused instruction while -ffp-contract is

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

On Mon, Aug 12, 2019 at 09:20:18PM +, Joseph Myers wrote: > On Mon, 12 Aug 2019, Segher Boessenkool wrote: > > > (define_insn "add_truncdfsf3" > > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") > > (float_truncate:SF > > (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")

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

On Mon, 12 Aug 2019, Segher Boessenkool wrote: > (define_insn "add_truncdfsf3" > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") > (float_truncate:SF > (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa") > (match_operand:DF 2 "gpc_reg_operand" "d,wa"]

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

On Mon, Aug 12, 2019 at 11:01:11PM +0530, Tejas Joshi wrote: > I have the following code in my rs6000.md (I haven't used new TARGET_* yet) : > > (define_expand "add_truncdfsf3" > [(set (match_operand:SF 0 "gpc_reg_operand") >(float_truncate:SF >(plus:DF (match_operand:DF 1 "gpc_r

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

Hi, I have the following code in my rs6000.md (I haven't used new TARGET_* yet) : (define_expand "add_truncdfsf3" [(set (match_operand:SF 0 "gpc_reg_operand") (float_truncate:SF (plus:DF (match_operand:DF 1 "gpc_reg_operand") (match_operand:DF 2 "gpc_reg_operand")))

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

Hi Tejas, On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote: > +(define_expand "add_truncdfsf3" > + [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand")) > + (plus:DF (match_operand:DF 1 "gpc_reg_operand") > + (match_operand:DF 2 "gpc_reg_operand")))] > + "TAR

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

Hello. > with it, but first get DP->SP (fadd) working? Can you please review what have I have been trying and facing the issues on patch : Thanks, Tejas On Sun, 11 Aug 2019 at 12:50, Segher Boessenkool wrote: > > Hi Tejas, > > On Sun, Aug 11,

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

Hi Tejas, On Sun, Aug 11, 2019 at 10:34:26AM +0530, Tejas Joshi wrote: > > As far as I understand that flag should set the behaviour of the fadd > > function, not the __builtin_fadd one. So I don't know. > > According to ISO/IEC TS 18661, I am supposed to implement the fadd > variants for foldin

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

Hi! > As far as I understand that flag should set the behaviour of the fadd > function, not the __builtin_fadd one. So I don't know. According to ISO/IEC TS 18661, I am supposed to implement the fadd variants for folding and expand them inline, that take double and long double as arguments and r

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

Hi! On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote: > I have been trying to write a basic pattern taking all the suggestions > you both have mentioned. The same patch is attached here, but I cannot > see call to : > > float > foo (double x, double y) > { > return __builtin_fadd (

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

Hello. I have been trying to write a basic pattern taking all the suggestions you both have mentioned. The same patch is attached here, but I cannot see call to : float foo (double x, double y) { return __builtin_fadd (x, y); } being expanded to any instruction, at least a simple one, using -f

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

On Thu, 8 Aug 2019, Segher Boessenkool wrote: > These current patterns all take the same mode for all inputs and outputs > (that's what 3 indicates, say, fadddf3). You will need to define > something that takes two SFs in and produces a DF. That cannot really For example, md.texi describes stan

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

Hi! On Fri, Aug 09, 2019 at 12:14:54AM +0530, Tejas Joshi wrote: > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > > which could be extended to allow DF inputs with an SF output; it doesn't > > yet allow it. > > This might be very lousy but I am confused with the optabs and i

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

Hi. It took some time for me to finish with the folding part for fadd variants and till it is reviewed, I want to move ahead with power8/9 expansions on top of the current fadd patch. > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > which could be extended to allow DF inputs wi

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

On Wed, Jul 31, 2019 at 12:23:18PM +0530, Tejas Joshi wrote: > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > > which could be extended to allow DF inputs with an SF output; it doesn't > > yet allow it. > > Thanks for the inputs, I will try to address these points now. I have

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

Hi, > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > which could be extended to allow DF inputs with an SF output; it doesn't > yet allow it. Thanks for the inputs, I will try to address these points now. I have built GCC on gcc112 and will apply patch and test testcases there

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

On Tue, 30 Jul 2019, Florian Weimer wrote: > * Martin Jambor: > > > as you might know, Tejas is our Google Summer of Code student working on > > adding built-in functions for some new math functions added in ISO/IEC > > TS 18661. > > > > His next step is to expand "functions rounding result to na

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

On Mon, 29 Jul 2019, Segher Boessenkool wrote: > I think this is refering to the "fadds" and similar Power architecture > instructions, which take as inputs any single or double precision > numbers, and round the result to single precision? These instructions Yes. On Power9, it is *also* possib

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

* Martin Jambor: > as you might know, Tejas is our Google Summer of Code student working on > adding built-in functions for some new math functions added in ISO/IEC > TS 18661. > > His next step is to expand "functions rounding result to narrower type" > (so fadd, fsub and possibly fmul and fdiv d

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

Hi! On Mon, Jul 29, 2019 at 07:37:53PM +0200, Martin Jambor wrote: > as you might know, Tejas is our Google Summer of Code student working on > adding built-in functions for some new math functions added in ISO/IEC > TS 18661. > > His next step is to expand "functions rounding result to narrower

Expansion of narrowing math built-ins into power instructions

Hi Segher, as you might know, Tejas is our Google Summer of Code student working on adding built-in functions for some new math functions added in ISO/IEC TS 18661. His next step is to expand "functions rounding result to narrower type" (so fadd, fsub and possibly fmul and fdiv described in http: