[llvm-dev] TargetSelect.h and layering

[Chandler Carruth via llvm-dev]

Yes, "all" is "all configured" I think throughout this discussion. Sorry
for that confusion.

On Thu, Dec 7, 2017 at 6:09 PM Robinson, Paul <paul.robinson at sony.com>
wrote:

> Could you guys clarify one thing for me?  It sounds like the idea is that
> the current model of configuring the selection of targets would go away, to
> be replaced by an all-or-native-only switch.  Sometimes I like to configure
> X86+ARM because that reduces rebuild time and still gets me the vast
> majority of debug-info tests.
>
> Or maybe you're using "all" as a shorthand for "all configured targets"
> which would be just fine.
>
> Thanks
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Chandler
> Carruth 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 the "all" libraries and links everything together.
>
>
>
> Last but not least, I think in this world we'd want each of the narrow,
> specific interfaces to be *inside* the individual target libraries rather
> than squeezed into a single header file.
>
>
>
> But this is a lot of churn and work. So I'm not seeing a huge problem if
> it is ust too much churn and work and you make the header a textual header
> for now. I'd document this super clearly in the header and lift it up a
> directory to live alongside our other textual headers like LinkAllPasses.h
>
>
>
> On Thu, Dec 7, 2017 at 2:10 AM Eric Christopher <echristo at gmail.com>
> wrote:
>
> My only alternate ideas are:
>
>
>
> a) To heck with this only a single target thing.
>
> b) Autogenerate the entire file and library support as part of the build
> and have the various functions "defined" in the appropriate libraries.
>
>
>
> I don't really think a) is feasible, and b) is a bit of a stretch too. :\
>
>
>
> -eric
>
>
>
> On Mon, Dec 4, 2017 at 5:37 PM David Blaikie <dblaikie at gmail.com> wrote:
>
> Ping - any further/other thoughts from folks? I'm not /too/ fussed, but
> generally like the idea of lib layering being simple/clear/obvious, but
> understand these are sort of the degenerate/worst case.
>
>
>
> On Tue, Nov 28, 2017 at 12:12 PM David Blaikie <dblaikie at gmail.com> wrote:
>
> On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <rnk at google.com> wrote:
>
> 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.
>
>
> Not sure about that - yeah, it's a bit of the degenerate case, for sure.
>
> But in a build system like Google's, where a lib has other lib
> dependencies (whereas in the LLVM CMake build it seems libs don't depend on
> other libs - so every executable has to explicitly list its transitive lib
> dependencies) it's pretty nice to have these little libraries explicitly in
> the build graph - much like we have those synthetic library targets in the
> CMake rules, so it's easy to depend on the right/full things.
>
> (but because the CMake lib rules for LLVM don't actually describe lib
> dependencies, I think even 'fixing' this in upstream LLVM wouldn't make the
> dep situation better - the synthetic targets would just have to expand to
> the underlying libs + the wrapper/selector lib as well)
>
>
> I'd mark it textual and leave it alone.
>
>
> Yeah, maybe... just makes me a bit sad to have inline functions that can't
> be trivially out-of-lined if/when desired, because they layering 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171207/1ce34c57/attachment-0001.html>