https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231
Uroš Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glisse at gcc dot gnu.org --- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Richard Biener from comment #1) > Confirmed. Last time this was Honzas estimation changes, thus CCing Honza > (aka, I told you so before). > > 160517.34236301 ... 48.68 > 160518.25236346 ... -1.00 > 160519.34236434 ... 155.92 > > so unfortunately we have one broken run but the above "encodes" the revision > range 236301 (good) to 236434 (bad). The other tester constrais the revision > range to 236299 (good) to 236427 (bad). > > It might be the add-to-multiply reassoc which also applies to x + x, > producing > 2 * x which is eventually vectorized to comparatively very slow code (in case > of integers). There is a regression bug showing we need to fix this in > vectorizer pattern recog. Nope, this time reghunt points to r236338: Log: x & C -> x if we know that x & ~C == 0 2016-05-17 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd (X & C): New transformation. Reverting r236338, the -Ofast runtime on my x86_64-linux-gnu box goes from 0m24.650s to 0m15.037s.