search for: alltarget

...ssues 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)...

...n’t > have an explicit arch/feature/whatever setting on the RUN line and run it > with all available -mcpu= values and see if it still passes (which is what > the lack of such things on the RUN line implies). We should totally do this. We'll could have 'check' and 'check-alltargets' targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140411/989ea7a8/attachment.html>

...via llvm-dev Sent: Wednesday, December 06, 2017 5:14 PM To: Eric Christopher Cc: llvm-dev; Richard Smith Subject: Re: [llvm-dev] TargetSelect.h and layering FWIW, I think the end state we'll end up wanting is what you describe in your email: fine grained dependencies and something like libLLVM{AllTargets,NativeTarget}{AsmPrinters,AsmParsers,Descs,Disassemblers,Infos} I think the "Native" thing can be solved by having a CMake (and llvm-config) level alias that points to a specific single target library. Then I think you could actually build lib/Target/All/... directory tree that provides...

...ayering >> isn't fully/correctly represented in the build system. Modular codegen's >> been a good justification to flush out & fix several of these tricksy >> layering violations in LLVM already. >> >> >>> >>> 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 ---...

On Thu, Apr 10, 2014 at 7:41 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Apr 10, 2014 at 6:32 PM, Jim Grosbach <grosbach at apple.com> wrote: >> >> It's very important that a run of "llc" on one machine produce the same >> output on two heterogenous machines given the same input and command lines*. >> That's not true right now,