http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011-08-24 Target Milestone|--- |4.7.0 Summary|[4.7 regression] Huge build |[4.7 Regression] Huge build |time regression (Firefox |time regression (Firefox |lto build) |lto build) Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-24 08:29:05 UTC --- Using memcmp instead of strcmp may be one reason this is slower (I think we inline strcmp but don't have any fancy memcmp inline implementations). Thus, you might want to try s/memcmp/strcmp/ in eq_string_slot_node. Also the hash-function changed by using an initial value of ds->len instead of zero. And (unsigned)ds->s[i] is not equal to (unsigned char)ds->s[i] (but no difference on x86_64). I also wonder if we can speed up string hashing by use of some fancy SSE12345 instructions. Now, in general I think we lose all the bitpack compile-time optimizations by no longer being able to inline them. They were crafted so that doing bp_pack_value (bp, val1, 12); bp_pack_value (bp, val2, 4); results in a single shift and or instructions. Now it's going to be function calls :/ Please consider moving those primitives back to a header file.