[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.