[C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)

[Joseph S. Myers]

On Mon, 17 Jun 2013, Jakub Jelinek wrote:

> The following patch shows a performance regression caused by the C++ changes
> to evaluate side-effects in x += foo (); first and only then do the
> addition.  Previously if x was say int and foo () returned unsigned long
> long, convert_to_integer would narrow the addition to unsigned int, but
> as we now pass to convert_to_* a COMPOUND_EXPR with the side-effects on the
> op0 and addition on op1 of the COMPOUND_EXPR, convert_to_integer doesn't
> perform this shortening and unfortunately we don't have any gimple
> optimization yet to do this later on.  This patch fixes it by handling
> COMPOUND_EXPR in convert_to_* where we care about TREE_CODE of the expr.
> 
> Ok for trunk?  Ok for 4.8 as well after a while?

I suppose it's OK to fix the regression, though really we should be 
eliminating these early convert_to_* optimizations (optimizing later on 
GIMPLE if possible) rather than adding to them.

-- 
Joseph S. Myers
joseph@codesourcery.com