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 jos...@codesourcery.com
