[PATCH] Review: Add Cmake Options to disable target components (AsmParser, InstPrinter, Disassembler)

[Chandler Carruth]

On Sat, Apr 12, 2014 at 11:44 PM, Owen Anderson <resistor at mac.com> wrote:

> Chandler,
>
> On Apr 12, 2014, at 7:46 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> We already have separate libraries for some of these components (the
> disassembler at least is cleanly factored out). Why not refactor the target
> initialization code, etc., so that tools which don't need the various bits
> of a particular target can easily just not link that sub-library?
>
>
> That approach only makes sense in the context of linking LLVM statically.
>  We are trying to use LLVM as a dynamic library, and we’re very concerned
> about minimizing the distribution and storage footprint of that library.
>

So, I think I understand that. Is there anything weird or special about the
dynamic library, or is it just essentially 'libMyLLVM.so' (or dylib, or
whatever) that contains all of the LLVM bits you need?

Assuming its just a big shared library with the LLVM bits (and whatever
other bits) you need, you're essentially composing this shared library out
of several smaller LLVM archives. I'm suggesting that you vary which
smaller archives get linked in between the debug and the release shared
library. (more details below)


>
> I also disagree that requiring source changes in the client application to
> determine whether, say, the assembler printer for a given target is linked
> in or not is a good idea.
>

I'm not trying to suggest source changes in the client code. I think all of
the source changes can and should be isolated to common parts of LLVM
itself.


> It’s very important for us to be able to have client applications log
> final assembly for during development and debugging, but we don’t want to
> pay the binary size overhead when we deploy.  Aditya’s patch addresses that
> need by saying that we’d build our release builds with different build
> settings than our debug builds, which is already the case in lots of other
> ways.  What you’re proposing requires the client applications (which are
> linking against a shared LLVM library) to know when the LLVM library was
> built for deployment or development.
>

Not really. LLVM can always provide stubs that handle the difference
between deployment vs. development here.

You still need some way to control whether the assembly is dumped, etc. I
would suggest using one of the *existing* build parameters for that such is
NDEBUG, or even commandline flags, which just produce an error if the
assembly printing library isn't available in whatever mode it is being
built.

The really important thing for me is that we don't end up with yet more
permutations of ways to build the actual targets themselves. Instead, I
feel like clients of the *target* (which might be some umbrella LLVM
library, or the opt tool, or whatever else you have) can be clients of just
the core sub-libraries of the target or also of the asm printing in the
target. If they use the asm printing, then they have to get linked against
the asm printing sub-library. But the target is always built into these
smaller sub-libraries and doesn't need to be aware of this
parameterization. Is this making sense? Perhaps we are talking past each
other if not...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140416/2e3f2842/attachment.html>