Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
On Mon, Jun 17, 2013 at 6:54 PM, Joseph S. Myers 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.
Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
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 GIMPLE if possible) rather than adding to them. My thought as well. How hard is it to fix this in gimple fold? PRs for it are open for almost 3 years now, I think Kai has some patch, but it hasn't been posted yet, so it is unclear if it would make 4.9. Kai, what's the status of this patch? Jason
Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
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 them. > > My thought as well. How hard is it to fix this in gimple fold? PRs for it are open for almost 3 years now, I think Kai has some patch, but it hasn't been posted yet, so it is unclear if it would make 4.9. In any case, it isn't probably something that can be backported to release branches, while perhaps this simple convert.c change is. Once we have it in GIMPLE, sure, the change in convert.c can be happily reverted and also those optimizations removed from there too. Jakub
Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
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 fold? Jason
Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
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
