http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.6.0
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-12-12 16:49 ---
Subject: Re: reassoc can sometimes get in the way of PRE
>
> Here is a slightly modified example that shows that there's still a PRE
> opportunity
>
> void motion_test22(int * data, int i)
> {
> int j;
> if (da
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2006-12-12
06:07 ---
(In reply to comment #5)
> (In reply to comment #1)
> > Confirmed (but it's not PRE).
> >
> The second is smaller, and no more or less efficient since the addition is
> calculated on both paths anyway.
>
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-12-09 15:06 ---
(In reply to comment #1)
> Confirmed (but it's not PRE).
>
This actually is a case of PRE, because data[0] + data[3] is partially
redundant.
But according to the results, we *did* do the load PRE here.
In fact, P
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-12-09 14:40 ---
Uh, before declaring it a reassociation issue, why don't you try turning off
reassoc and see if it actually fixes the problem.
As long as reassoc rewrites it the same everywhere, it would still be PRE'd.
--
htt
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-09 06:51 ---
This is just an reassiocation issue, if we have a_1 + b_2 + 1, we change it to
be a_1 + 1 + b_2 which seems wrong. I wonder if we are trying to put the
constant first but when calling fold, it puts it second in the
