[PATCH] D33843: Create a new library called ObjectLayout, and move headers from Support to there.

[Zachary Turner via Phabricator via llvm-commits]

zturner added a comment.

Responding to blaikie since responding by email triggers moderation:

> I'm still missing some of the motivation as to 'why', here.
>  If there are significant uses of a library that don't use most of it - yeah, i think there's merit in separating things out (eg: if lld, lldb, etc, use, say, the DWARF constants but not the rest of Support/ADT - yeah, it'd be nice if they didn't have to rebuild whenever SmallString changed, for example). (though even then, Ninja's pretty efficient about only rebuilding what it has to, so I'm not sure that even the library granularity changes much about the build performance here - header dependency could be something to care about there, for sure (fewer long chains of dependent headers, breaking a header into two if there's functionality that is used broadly next to functionality that has a narrow use, etc).
>  What's the goal/metric/benefit?

First, there is the intangible benefit.  DWARF.h and WASM.h simply do not make logical sense in Support.   This might seem like a minor point, but I put this into the "technical debt" category.  By not enforcing strict guidelines of what goes into Support, we build up technical debt over time as a bunch of unrelated stuff piles into it.  We can do better than this.

Second, libraries as an abstraction are virtually free, and the point of them is to group related things together.  One could probably even argue they are better than free, as they have less than or equal to zero cost since at worst they do nothing, and at best they speed up your build and reduce your binary size.

Third, there is the practical benefit.  The only LLVMBuild.txt files modified here are lib/IR and lib/Object.

Any tool that did not depend on one of those two libraries should now build faster and be smaller in binary size.  I don't have a list of which tools satisfy that condition, however, but it's definitely non-empty (FileCheck, for example, is an obvious candidate).


https://reviews.llvm.org/D33843