This is the mail archive of the
mailing list for the GCC project.
Re: Expansion of narrowing math built-ins into power instructions
On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <email@example.com> writes:
> > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> >> Segher Boessenkool <firstname.lastname@example.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.
It's the same for 32-bit:
mips-linux-gcc -Wall -W -O2 -S mulh.c -mips32 -mabi=32
(I hope these options are reasonable? I don't know MIPS well at all).
Trying 12 -> 20:
Failed to match this instruction:
(set (reg/i:SI 2 $2)
(subreg:SI (mult:DI (zero_extend:DI (reg:SI 204))
(zero_extend:DI (reg:SI 205))) 0))
The point is that this is the form that this insn is simplified to. If
that form is not recognised by your backend, various optimisation
opportunities are missed.
> 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.)
Does it even know if the rounding mode is one of the IEEE FP rounding