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
libLLVM{AllTargets,NativeTarget}{AsmPrinters,AsmParsers,Descs,Disassemblers,Infos}
?
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>
Alternatively we can really say this header is a textual header - it's included generally only once in a whole program, the functions are called only once, etc. Though that does seem a little unfortunate on principle but not much practical problem with it, I think. It'd be nice in theory to be able to depend on the right library, have that bring in the right dependencies, etc. On Tue, Nov 28, 2017 at 11:15 AM David Blaikie <dblaikie at gmail.com> wrote:> 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 > libLLVM{AllTargets,NativeTarget}{AsmPrinters,AsmParsers,Descs,Disassemblers,Infos} > ? > > 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/5cd2e2c7/attachment.html>
On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Alternatively we can really say this header is a textual header - it's > included generally only once in a whole program, the functions are called > only once, etc. Though that does seem a little unfortunate on principle but > not much practical problem with it, I think. It'd be nice in theory to be > able to depend on the right library, have that bring in the right > dependencies, etc. >As designed, TargetSelect.h doesn't fit neatly into the normal way of arranging libraries. I'd mark it textual and leave it alone. Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all the other synthetic libraries in CMake into real libaries and sink the bodies of these inline functions into each tiny little library. Doesn't seem quite worth it, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171128/af07ebc7/attachment.html>