[CodeGen] Optimize AccelTable
ClosedPublic

Authored by labath on Feb 8 2018, 7:34 AM.

Details

Summary

The class contained arrays of two structures (DataArray and HashData).
These structures were in 1:1 correspondence, and one of them contained
pointers to the other (and *both* contained a "Name" field). By merging
these two structures into one, we can save a bit of space without
negatively impacting much of anything.

Diff Detail

Repository
rL LLVM
labath created this revision.Feb 8 2018, 7:34 AM
JDevlieghere accepted this revision.Feb 8 2018, 8:34 AM

Thanks! I had noticed this too when doing the refactoring earlier, but hadn't gotten around to looking into it yet.

This revision is now accepted and ready to land.Feb 8 2018, 8:34 AM
Closed by commit rL324724: [CodeGen] Optimize AccelTable (authored by labath, committed by ). · Explain WhyFeb 9 2018, 2:10 AM
This revision was automatically updated to reflect the committed changes.
labath added inline comments.Feb 9 2018, 4:23 AM
llvm/trunk/include/llvm/CodeGen/AccelTable.h
239

I see one more (and possibly bigger) improvement that we can make here:
This string map will store a copy of the string from the HashData structure (along with it's hash, which it will need to recompute). However, HashData already contains a hash *and* the string, which has even been uniqued by the dwarf string pool.

So, we could store the HashData in a DenseMap (with a custom DenseMapInfo) and save both space (no string copies) and time (efficient equality comparison).

The only additional requirement here would be that all the DwarfStringPoolEntryRefs come from a single string pool. As far as I can tell, this is already the case (and I can't imagine why one would do it differently), but I don't see a way to enforce that in code.

WDYT?