This is the mail archive of the
mailing list for the GCC project.
Re: Expansion of narrowing math built-ins into power instructions
Segher Boessenkool <firstname.lastname@example.org> writes:
> On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool <email@example.com> 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
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.)