On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <seg...@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
