[PATCH] D11805: Make DwarfAccelTable customizable. NFC.
Eric Christopher via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 15 14:23:30 PDT 2015
echristo added a comment.
In http://reviews.llvm.org/D11805#238925, @friss wrote:
> In http://reviews.llvm.org/D11805#238845, @echristo wrote:
>
> > 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)
http://reviews.llvm.org/D11805
More information about the llvm-commits
mailing list