------- 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, PRE does the address calculation elimination too.
Replaced *data_3 with prephitmp.26_35 in D.1635_18 = *data_3;
Replaced data_3 + 12B with prephitmp.24_33 in D.1636_19 = data_3 + 12B;
Replaced *D.1636_19 with prephitmp.26_37 in D.1637_20 = *D.1636_19;
The above is the perfect, expected, PRE result for this testcase.
The real difference in assembly here is because in motion result duplicates the
actual addition, and we just leave it as the result of a phi merge of the two
variables.
IE motion_results produces
j = blah1 + blah2
in both the if and else block, and merge the j result
motion_test2 keeps one copy of
j = blah1 + blah2
in the main code path, and merges the blah1 and blah2 results
The second is smaller, and no more or less efficient since the addition is
calculated on both paths anyway.
Both are valid results, and what RTL does with them is it's business.
I don't believe you can claim they should generate identical assembly.
The actual thing this testcase is trying to test, that load-PRE is performed,
has succeeded.
Thus i am closing this bug as WORKSFORME.
If you see something *actually wrong* with the result, rather than just
disassembly, please feel free to reopen.
--
dberlin at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
