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

[Richard Sandiford <richard.sandiford@arm.com>]

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.

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

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

Besides, how much depends on target-independent code not knowing what
the rounding mode is?  Do you think float_narrow would still make
sense even if more information was available at compile time
(e.g. if a plus could be annotated with a specific rounding mode)?
Or is not knowing the rounding mode a fundamental part of float_narrow
being OK for you?

> 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 the same thing.)

Thanks,
Richard