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

[Richard Biener]

On Mon, Jun 17, 2013 at 6:54 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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.

I agree.  The correct place for this is in tree-ssa-forwprop.c (for now).

Richard.