This is an archive of the discontinued LLVM Phabricator instance.

DWZ 02/12: refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract()
ClosedPublic

Authored by jankratochvil on Nov 18 2017, 1:14 PM.

Details

Summary

It has no functionality effect but I find it much more simplified for further refactorizations and extensions in my patchset.

I was concerned about the worse performance of DWARFDebugInfo::Parse this way of allocating+destroying a CU for each iteration but I see it is now used only by DWARFDebugInfo::Dump so that is no longer a problem.

Diff Detail

Repository
rL LLVM

Event Timeline

jankratochvil created this revision.Nov 18 2017, 1:14 PM
labath edited edge metadata.Nov 19 2017, 2:08 AM

You're using a fairly novel (to this codebase at least) simplification technique, so I think we should discuss that first. The way we have normally done these things is to just have the constructor call the Clear() function.

Personally, I am not really sure what to think about this approach. On one side, I kinda like it, but on the other one, it feels somewhat dodgy.

clayborg edited edge metadata.Nov 19 2017, 10:13 AM

Good change in the header file. I am not sure I like the destruct this object in place and replace with new version... If this is commonly done and acceptable form of C++ I would be ok with it, but I agree with Pavel, it seems a little bit off the books.

Good change in the header file.

If you mean the in-class initializers they obviously cannot be used without the in-place construction+destruction as they would stay duplicate to the Clear() method.

OK if you are also uncomfortable with it I will keep Clear() as is and just call Clear() from the ctor to unify it at least a bit.

Good change in the header file.

If you mean the in-class initializers they obviously cannot be used without the in-place construction+destruction as they would stay duplicate to the Clear() method.

OK if you are also uncomfortable with it I will keep Clear() as is and just call Clear() from the ctor to unify it at least a bit.

Or we can get rid of Clear(), make the constructor private and make DWARFCompileInit::Extract be static and return a shared pointer as suggested in your other patch. I doubt many compile units fail to construct so we can just avoid the Clear() call all together and keep the initialization in the header file. Let me know

jankratochvil retitled this revision from refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers to refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract().
jankratochvil edited the summary of this revision. (Show Details)
jankratochvil edited the summary of this revision. (Show Details)

DWZ support

refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract()

It has no functionality effect but I find it much more simplified for further
refactorizations and extensions in my patchset.

I was concerned about the worse performance of DWARFDebugInfo::Parse this way
of allocating+destroying a CU for each iteration but I see it is now used only
by DWARFDebugInfo::Dump so that is no longer a problem.

Differential revision: https://reviews.llvm.org/D40212

jankratochvil retitled this revision from refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract() to DWZ 02/12: refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract().Nov 26 2017, 5:07 AM
clayborg accepted this revision.Nov 27 2017, 10:07 AM

Won't hold up the checkin for the cleaner while loop, but feel free to fix that and checkin if it works.

source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
248–249 ↗(On Diff #124290)

Might be cleaner to do:

DWARFCompileUnitSP cu;
while ((cu = DWARFCompileUnit::Extract(dwarf2Data, &offset))) {
This revision is now accepted and ready to land.Nov 27 2017, 10:07 AM
jankratochvil added inline comments.Nov 29 2017, 1:11 PM
source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
248–249 ↗(On Diff #124290)

I did not know LLVM style can be this brief, that is sure better, implemented.

This revision was automatically updated to reflect the committed changes.