This is an archive of the discontinued LLVM Phabricator instance.

Make DwarfAccelTable customizable. NFC.
Needs ReviewPublic

Authored by friss on Aug 6 2015, 8:59 AM.

Details

Reviewers
dblaikie
echristo
Summary

Make DwarfAccelTable customizable. NFC.

I sent a couple of patches out a couple of month ago to basically achieve
the same thing in a more convoluted way (by having one class trying to
handle all possible cases).

Instead of making the API of the class fully generic (which makes the
code a mess), allow customization of the accelerator table by:

  • basing its behavior on a virtual class defining the type of the ATOMs it stores (the HashDataContents class).
  • Making it a base class that needs to be derived to provide the right factory functions for the content.

This NFC patch only provide on derived type DIEDwarfAccelTable with 2
variants (one describing types that dumps the additinal field).
llvm-dsymutil can use this to create tables that contain raw DIE offsets
instead of DIE pointers, and Adrian has a use where he store strings
instead of DIEs.

The HashDataContents gains a virtual pointer, but stays the same size
as I dropped an unused field. We can move the virtual inheritance to
the DwarfAccelTable itself in a followup, but this would be more code
(and thus harder to review) as it requires that the generic code iterates
over a vector of opaque data rather than the handy HashDataContents *.

Diff Detail

Event Timeline

friss updated this revision to Diff 31451.Aug 6 2015, 8:59 AM
friss retitled this revision from to Thread premissions through sys::fs::create_director{y|ies}.
friss updated this object.
friss added reviewers: echristo, dblaikie.
friss added a subscriber: llvm-commits.
friss updated this revision to Diff 31452.Aug 6 2015, 9:01 AM

Try to include only the relevant change in the Phad revision this time...

friss retitled this revision from Thread premissions through sys::fs::create_director{y|ies} to Make DwarfAccelTable customizable. NFC..Aug 6 2015, 9:02 AM
friss added a comment.Aug 6 2015, 9:05 AM

Sorry about the mess with the diff/revision title. My topic branch had one more uncommitted change when I ran "arc diff" and I wasn't careful enough while reading the text...

echristo edited edge metadata.Aug 7 2015, 10:05 AM

I'd think there's something in the middle here. The code is a bit of a hack originally and this cleans up some, but makes some of it a bit worse. I'm not quite sure where you're going with it, ideally we should be able to base everything here off of the atoms in the stack that this uses. Could we do that? (Mostly throwing out ideas here...).

-eric

friss added a comment.Aug 7 2015, 10:16 AM

I have this revision lying around where the code is driven by what's in the atom list:
http://reviews.llvm.org/D8215 (it's based on this other one http://reviews.llvm.org/D8216 that you ack'd but that I didn't commit as it doesn't make much sense without the former)

I find this approach clearer. Rather than adding a special case for storing DIE offsets instead of DIE pointers, I'll just derive a new table type.

As I mentioned, Adrian has a use that create a totally different table without even DIEs. He's still pondering if he wants to upstream that or do it differently, but this one would make the code even uglier with other special cases.

Sorry for the delay. The idea behind the current implementation is to be able to derive it from the atom list. I guess if we just want "variant" tables we could instead just instantiate the type of table we'd like for the output information and just store "things we'd like to put into the table" in the intermediate state as we're constructing DIEs?

-eric

friss added a comment.Sep 2 2015, 6:44 PM

Sorry for the delay. The idea behind the current implementation is to be able to derive it from the atom list. I guess if we just want "variant" tables we could instead just instantiate the type of table we'd like for the output information and just store "things we'd like to put into the table" in the intermediate state as we're constructing DIEs?

I was just going to ping you about this, it's really blocking me right now. Not sure I get what you mean exactly. Care to elaborate on a concrete example? The one I have to handle right now is that I can't store DIE pointers in the table because my DIE objects go away before we emit the table, thus I have to store raw DIE offsets instead. I can do that by adding a config boolean to the table and making the DIE* a union with the offset. Is that what you mean?

When doing this the data emission part of the code gets a bit ugly because it has to handle all the different cases. I had that implemented internally, but we had an additional change by Adrian that made it really too ugly to live. I think that last change is not necessary anymore, so I could definitely implement it this way if it's ok with you. (This is basically what was proposed in http://reviews.llvm.org/D8215 + http://reviews.llvm.org/D8216 if you wanna get a feel of what it looks like. I'd need to update these to current master)

Sorry for the delay. The idea behind the current implementation is to be able to derive it from the atom list. I guess if we just want "variant" tables we could instead just instantiate the type of table we'd like for the output information and just store "things we'd like to put into the table" in the intermediate state as we're constructing DIEs?

I was just going to ping you about this, it's really blocking me right now. Not sure I get what you mean exactly. Care to elaborate on a concrete example? The one I have to handle right now is that I can't store DIE pointers in the table because my DIE objects go away before we emit the table, thus I have to store raw DIE offsets instead. I can do that by adding a config boolean to the table and making the DIE* a union with the offset. Is that what you mean?

I hadn't thought through that detail when I sent my response, but it seems reasonable. Maybe a union of "things we'll use in the table" sort of thing and then use that as the target for the vector?

union TableEntry {

DIE *Entry;
uint64_t offset;
...

}

and keep track via the atom list what things we think we've actually got and access that way?

Am I crazy in thinking this seems good?

-eric

When doing this the data emission part of the code gets a bit ugly because it has to handle all the different cases. I had that implemented internally, but we had an additional change by Adrian that made it really too ugly to live. I think that last change is not necessary anymore, so I could definitely implement it this way if it's ok with you. (This is basically what was proposed in http://reviews.llvm.org/D8215 + http://reviews.llvm.org/D8216 if you wanna get a feel of what it looks like. I'd need to update these to current master)