This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PTR-PLUS merge into the mainline


On Thu, 5 Jul 2007, Roman Zippel wrote:

> Hi,
> 
> On Thu, 5 Jul 2007, I wrote:
> 
> > Exactly and that's why I think this transformation is done far too early. 
> > It doesn't make sense that these two examples produce different code:
> > 
> > int foo1(int x)
> > {
> > 	return (x * 4) + 4;
> > }
> > int foo2(int x)
> > {
> > 	int y = x * 4;
> > 	return y + 4;
> > }
> 
> Another example:
> 
> int foo3(int x, int y)
> {       
> 	return (x * y) + (y * 5);
> }
> int foo4(int x, int y)
> {       
> 	x *= y;
> 	return x + (y * 5);
> }
> 
> Here the generated code depends on how the constant multiply is expanded, 
> so that combine can do the optimization.

int foo5(int x, int y)
{
        x += 5;
        return x * y;
}

If there is anything to fix, then all those variants should produce
the same code, not just foo3 and foo4.  So for these cases we should
make sure that value-numbering sees them as computing the same value
and extend combine to choose the instructions with the least cost.

Changing fold isn't a real fix.  It's a workaround for a specific
testcase.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]