This library will be the home of a new resolution-based LTO interface (D20268),
which should not be confused with the existing legacy LTO interface in this
directory.
Details
Diff Detail
Event Timeline
Can you mention what is a "resolution-based LTO interface" and why do we need a separate library?
(Or points to another revision if it was discussed somewhere else)
OK, having a separate library needs some motivation, I think this has be diluted in the original discussion so I lost track of it.
The name "Resolution" made me think that it'll be a sub-part of the LTO component of LLVM dealing *only* with symbol-resolution.
This seems very "artificial" to me and I'm not convince a new library is justified right now.
In include/llvm/LTO/ I can see: LTOCodeGenerator.h LTOModule.h ThinLTOCodeGenerator.h
What's the plan for all of that? If we're just dealing with legacy here, I'd just move all these into include/llvm/LTO/legacy/ instead. There's not much harm to have the three implementation file in lib/LTO.
At some point if libLTO.dylib is the only remaining user for these interface and the implementation targets the new LTO API, they could be moved to tools/lto/* and the header made private there.
If we're just dealing with legacy here, I'd just move all these into include/llvm/LTO/legacy/ instead.
I think that would work as well, but I wanted to make a clean break.
We'll also have LTOBackend.cpp which will be used by clang. I think Teresa mentioned some problems depending on the existing LTO library from clang, but let me see if I can get it to work. If not, I guess we can move the implementation to lib/LTO/Legacy.
I don't remember if it was theoretical or if I tried this and ran into
issues. Thinking about it some more now - I suppose adding new dependence
from clang to llvm should never introduce a circular dependence? So I don't
know what I was concerned about...
A local change which replaced the dependency on LTOResolution with LTO seems to work, so I've done as Mehdi suggested.