[PATCH] for PR 18219

[Zdenek Dvorak]

Hello,

> There was one curious (but safe) change however:
> 
> > *************** fold (tree expr)
> > *** 6612,6621 ****
> >   	      if (TREE_CODE (parg0) != MULT_EXPR
> >   		  && TREE_CODE (parg1) == MULT_EXPR)
> >   		return fold (build2 (PLUS_EXPR, type,
> > ! 				     fold (build2 (PLUS_EXPR, type,
> > ! 						   fold_convert (type, parg1),
> > ! 						   fold_convert (type, marg))),
> > ! 				     fold_convert (type, parg0)));
> >   	    }
> >
> >   	  if (TREE_CODE (arg0) == MULT_EXPR && TREE_CODE (arg1) == MULT_EXPR)
> > --- 6616,6626 ----
> >   	      if (TREE_CODE (parg0) != MULT_EXPR
> >   		  && TREE_CODE (parg1) == MULT_EXPR)
> >   		return fold (build2 (PLUS_EXPR, type,
> > ! 				     fold_convert (type, parg0),
> > ! 				     fold (build2 (pcode, type,
> > ! 						   fold_convert (type, marg),
> > ! 						   fold_convert (type,
> > ! 								 parg1)))));
> >   	    }
> >
> >   	  if (TREE_CODE (arg0) == MULT_EXPR && TREE_CODE (arg1) == MULT_EXPR)
> 
> Here your change now generates "(plus (parg0) (foo))" instead of
> "(plus (foo) (parg0))".  My guess is that you originally investigated
> that the PLUS_EXPR needed to be "pcode", and swapped the order to keep
> them in the same order as the original.  If instead it's that there's
> another optimization that only recognizes "(plus X Y)" but not
> "(plus Y X)", then that needs fixing.

no, there is no special reason for swapping the operands (I probably did
it just that the trees produced by the optimization match those I drawed
on a piece of paper).

Zdenek