https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #9 from amker at gcc dot gnu.org --- (In reply to Ilya Enkovich from comment #8) > (In reply to amker from comment #7) > > According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html, > > hook is probably not wanted in this case. > > Bernd gave another proposal by moving combine before loop transforms is also > > interesting, but it can be for GCC6. > > So a backend fix would be nice. > > Unfortunately my patch causes significant regressions in some SPEC > benchmarks. Looks like address operands order matters in some other places. I know little about x86, is it because of generation of non-canonical rtl expression after this change? Another question for this case is: Is it because operand ordering that inv_can_prop_to_addr_use failed to verify the result insn as a valid one? If so, is it because of non-canonical rtl expressions? I will check how combine merges these two instructions. Thanks.
