llvm dev - Dec 2017 - TargetSelect.h and layering

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/8b89a3be/attachment.html>

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/7bb9ce14/attachment-0001.html>

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<mailto: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<mailto: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<mailto:dblaikie at gmail.com>> wrote:
On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <rnk at
google.com<mailto: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<mailto: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/4b8054b0/attachment.html>