[PATCH] middle-end: Improve RTL expansion in expand_mul_overflow,

Jakub Jelinek jakub@redhat.com
Thu Jul 9 08:29:44 GMT 2020


On Thu, Jul 09, 2020 at 09:17:46AM +0100, Richard Sandiford wrote:
> > --- a/gcc/internal-fn.c
> > +++ b/gcc/internal-fn.c
> > @@ -1627,6 +1627,9 @@ expand_mul_overflow (location_t loc, tree lhs, tree arg0, tree arg1,
> >  				     profile_probability::very_likely ());
> >  	  else
> >  	    {
> > +	      /* RES is used more than once, place it in a pseudo.  */
> > +	      res = force_reg (mode, res);
> > +
> >  	      rtx signbit = expand_shift (RSHIFT_EXPR, mode, res, prec - 1,
> >  					  NULL_RTX, 0);
> >  	      /* RES is low half of the double width result, HIPART
> 
> In general, this can be dangerous performance-wise on targets where
> subregs are free.  If the move survives to the register allocators,
> it increases the risk that the move will become a machine insn.
> (The RA will prefer to tie the registers, but that isn't guaranteed.)
> 
> But more fundamentally, this can hurt if the SUBREG_REG is live at
> the same time as the new pseudo, since the RA then has to treat them
> as separate quantities.  From your results, that obviously doesn't
> occur in the test case, but I'm not 100% confident that it won't
> occur elsewhere.
> 
> If target-independent code is going to optimise for “no subreg operand”
> targets like nvptx, I think it needs to know that the target wants that.

Isn't that though what the expander is doing in lots of places?
Force operands into pseudos especially if optimize to hope for better CSE
etc., and hope combine does its job to undo it when it is better to be
propagated?
It is true that if res is used several times, then combine will not
propagate it due to multiple uses, so the question I guess is why as Roger
says we get the same code before/after (which pass undoes that; RA?).

	Jakub



More information about the Gcc-patches mailing list