Segher Boessenkool <seg...@kernel.crashing.org> writes: > 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.
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
