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.
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" "=<Ff>,wa")
       (unspec:SF
       [(plus:DF (match_operand:DF 1 "gpc_reg_operand" "%<Ff>,wa")
                 (match_operand:DF 2 "gpc_reg_operand" "<Ff>,wa"))]
                  UNSPEC_ADD_TRUNCATE))]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")])

and an UNSPEC_ADD_TRUNCATE in unspec enum.

Thanks,
Tejas

On Wed, 21 Aug 2019 at 01:12, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote:
> > Segher Boessenkool <segher@kernel.crashing.org> writes:
> > > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> > >> Segher Boessenkool <segher@kernel.crashing.org> 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 avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION.
> > >
> > > Trying 10 -> 18:
> > >    10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI)
> > >       REG_DEAD r205:DI
> > >       REG_DEAD r204:DI
> > >    18: $2:DI=r200:TI#0
> > >       REG_DEAD r200:TI
> > > Failed to match this instruction:
> > > (set (reg/i:DI 2 $2)
> > >     (subreg:DI (mult:TI (zero_extend:TI (reg:DI 204))
> > >             (zero_extend:TI (reg:DI 205))) 0))
> > >
> > > I'm afraid not.
> >
> > That's TI->DI though, whereas the pattern above is DI->SI.  The modes
> > matter :-)  There'd also need to be a shift to match a highpart pattern.
>
> It's the same for 32-bit:
>
> mips-linux-gcc -Wall -W -O2 -S mulh.c -mips32 -mabi=32
> (I hope these options are reasonable?  I don't know MIPS well at all).
>
> Trying 12 -> 20:
>    12: r200:DI=zero_extend(r204:SI)*zero_extend(r205:SI)
>       REG_DEAD r205:SI
>       REG_DEAD r204:SI
>    20: $2:SI=r200:DI#0
>       REG_DEAD r200:DI
> Failed to match this instruction:
> (set (reg/i:SI 2 $2)
>     (subreg:SI (mult:DI (zero_extend:DI (reg:SI 204))
>             (zero_extend:DI (reg:SI 205))) 0))
>
> The point is that this is the form that this insn is simplified to.  If
> that form is not recognised by your backend, various optimisation
> opportunities are missed.
>
> > I wouldn't say it knows nothing about rounding.  It doesn't know
> > what the runtime rounding mode is, but that isn't the same thing.
> > (Just like not knowing what (mem:SI (sp)) contains isn't the same
> > thing as not knowing anything about stack memory.)
>
> Does it even know if the rounding mode is one of the IEEE FP rounding
> modes?
>
>
> Segher


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