On Mon, Jun 17, 2013 at 6:54 PM, Joseph S. Myers
jos...@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
Hi!
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
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
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
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.
My thought as well. How hard is it to fix this in gimple
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
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
On 06/17/2013 02:09 PM, Jakub Jelinek wrote:
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
