1865900 - Try optimizing string hash access on 32-bit by shifting the fat inline atom bit

Status: NEW

(Core :: JavaScript Engine, enhancement, P2)

Description

[Steve Fink [:sfink] [:s:]]

I'm not totally sure this would work, but currently when loading the hash value from an atom, the JIT grabs the flags, does a comparison to get a 0 or 1 depending on whether it's a fat inline atom, and then does some clever scaling stuff to use that 0 or 1 to add (or not add) 8 to the offset to load from.

I think the single bit 7 is enough to distinguish a fat inline atom from both a thin inline atom or an out of line atom. If that is true, then we could mask off that bit, shift it right by 4, add in the base offset (NormalAtom::hashOffset()), and then use that for the load offset.

Similar to:

    move32(Imm32(JSString::FAT_INLINE_MASK), outHash);
    and32(Address(str, JSString::offsetOfFlags()), outHash);
    constexpr uint8_t fatInlineBit = 7;
    constexpr uint8_t offsetDiffLog2 = 3;
    static_assert(FatInlineAtom::offsetOfHash() - NormalAtom::offsetOfHash() == (1 << offsetDiffLog2));
    rshift32(outHash, fatInlineBit - offsetDiffLog2, outHash);  // outHash is now 8 for fat inline, 0 otherwise
    add32(outHash, NormalAtom::offsetOfHash(), outHash);
    load32(Address(id, outHash), outHash);

The part I'm unsure of is whether normal non-inline atoms will always have bit 7 set to 0. But that could probably be made to be true if it isn't already. (The above code is not correct;
FAT_INLINE_MASK has both the "inline" and "fat" bits set.)

I'm also not sure this would be any faster. It has the same number of branches (zero), and accesses the same memory locations. It just drops an instruction or two, and I think it may use one less register than the existing code in MacroAssembler::prepareHashString.