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


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]