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.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Thanks! I had noticed this too when doing the refactoring earlier, but hadn't gotten around to looking into it yet.
llvm/trunk/include/llvm/CodeGen/AccelTable.h | ||
---|---|---|
239 | I see one more (and possibly bigger) improvement that we can make here: 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? |
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?