[llvm-dev] TargetSelect.h and layering

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 28 11:15:55 PST 2017

So, I'm setting about trying to fix the layering of TargetSelect.h (&
TargetRegistry.h, but haven't really got to its issues yet).

The issues can be demonstrated fairly plainly by moving any/all of
TargetSelect.h's functions out of line. Pretty much all programs in LLVM
fail to link because libSupport doesn't actually depend on all the targets,
quite the opposite in fact.

So, I set about creating a libLLVMAllTargets (for want of any better
name/as a straw man) & wherever LLVM_TARGETS_TO_BUILD was listed in a
CMakeLists.txt LLVM_LINK_COMPONENTS, I'd add in a dependence on AllTargets
(& I moved all the function definitions in TargetSelect.h out of line to
flush out/prove the dependencies were right).

A few problems:

It seems there are users of TargetSelect.h that want pretty much every
granular split of the functionality possible. For example:

* Some executables only depend on the asm parsers and only call
InitializeAllAsmParsers (similarly for any other All*) - see the various
AllTargetsAsmParsers and similar rules in cmake/modules/LLVM-Config.cmake
* Some executables depend only on the native target support
InitializeNativeTarget* functions - see the JIT tests and the "native" and
"nativecodegen" rules in the above cmake file.

So... - any ideas? Should we just give up some of this fine grained
dependency control & say you can only depend on all targets? (or maybe "all
targets or the native target" and I'll make two libraries -
libLLVMAllTargets and libLLVMNativeTarget?)
Do we keep the fine grained dependency & have

Happy to make any of that happen, but curious what people might prefer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171128/f9e69731/attachment.html>

More information about the llvm-dev mailing list