https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 37913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37913&action=edit gcc6-pr70127-hack.patch To gather some statistics on what the various changes to operand_equal_p affect or might affect, I've bootstrapped/regtested x86_64-linux and i686-linux trunk with the gcc6-pr70127-typecheck.patch and gcc6-pr70127-hack.patch, which should for every non-recursive opernad_equal_p call it 3 times - once the way current trunk does, once the way gcc6-pr70127-typecheck.patch would and once the way 5.x did, and reported any differences in what has been returned. That of course doesn't mean the different operand_equal_p actually affected some optimization, or changed generated code. The i686-linux bootstrap already finished, x86_64-linux is still regtesting, so the current results are partial, but I see 3458 lines with trunk 1 new 0 5.x 1 136 lines with trunk 1 new 0 5.x 0 and no others. Thus, the OEP_NO_TYPECHECK patch will affect more than 25 times what reversion of r229494 would affect. Therefore, I think the reversion is safest thing at this point, and we should reconsider after branching. If there is interest I can also attach the detailed log (with filenames/function names).
