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

This was
mips64-linux-gcc -Wall -W -O2 -S mulh.c -mips64 -mabi=64 -fdump-rtl-combine-all
on
===
typedef unsigned long S;
typedef unsigned __int128 D;

S mulh(S a, S b) { return (D)a*b >> (8*sizeof(S)); }
===

> >> float_narrow is different in that the plus (or whatever operation
> >> it's quoting) has to be kept in-place rather than folded away,
> >> otherwise the rtx itself is malformed and could trigger an ICE,
> >> just like the zero_extend of a const_int that I mentioned.
> >
> > Yes, it will not pass recog.  Structurally it is just hunky-dory though.
> 
> So maybe that's the main point of difference.  We're introducing
> float_narrow to modify another rtx operation rather than to operate
> on an rtx value.

I wouldn't say it "operates" on anything.  A float_narrow rtx means the
thing inside it does single-rounding to SP float.  And it is just
notation: RTL itself knows *nothing* about float rounding, and because
of the way this is structured, nothing can change anything about the
float_narrow.

And yes, it is icky.  But it is sound, as far as I can see.

> >> Whatever the number is, we'll still be listing them individually for
> >> built-in enumerations, internal_fn, and (I assume) optabs.  But maybe
> >> after a certain point it does become too unwieldly for rtx codes.
> >> We have to keep it within 16 bits at least...
> >
> > My main concern is all the (simplification) code that parses RTL.  All of
> > that will have to handle all variant versions as well.
> 
> True, but we'd have to err on the side of caution whatever happens.

Yes.

> Not all existing PLUS simplifications necessarily apply as-is.

Yes.  Everything will have to be checked.  But not everything will
have to be modified, if we pick the defaults carefully.  I hope.  :-)


Segher


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