https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Mar 2016, jakub at gcc dot gnu.org wrote: > 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. I agree. > If there is interest I can also attach the detailed log (with > filenames/function names). Yeah, can you attach it? (that's callers filenames/functions, right?)
