Virtual "components" for llvm-config

To ease portability headaches, I'd like to support several virtual "components" in llvm-config. Possibilities include:

   all: Include all LLVM libraries.
   backend: Include either a working native backend or cbackend.
   engine: Include a working subclass of ExecutionEngine, either the JIT or interpreter.

You could, for example, get a typical set of JIT-related libs using:

   $ llvm-config --libs engine bcreader scalaropts

Of course, the exact names and details are up to you folks. :slight_smile: But if you're building a project outside the LLVM tree, please let me know what I can do to make your life easier.

Cheers,
Eric

The only thing that comes to me off the top of my head is to look at the
various LLVM tools and applications and see if there are common sets of
libraries used by the tools. Ideally we'd want to "llvm-config --libs
{toolname}" for each tool where {toolname} is replaced by the virtual
component corresponding to the tool. That might be overkill, but if
there are multiple tools that share the same set of libraries, it makes
sense to me that those comment library sets be implemented as virtual
components.

In looking at tools, we should also look at the example programs and the
projects such as Stacker. For example, it would be nice to have a
virtual component that includes the libraries necessary for an LLVM
front end translator (source -> llvm bytecode). It would also be nice
to have a virtual component that includes the libraries necessary for an
LLVM back end target library (LLVM IR -> machine code). There are
probably a few other categories, for example utilities that only mess
with passes (e.g. opt, LLVM bc -> LLVM bc).

The other ones you've mentioned seem fine, but I could add:

      * transform: Include libraries needed to read and write bytecode
        as well as implement a transform on the LLVM IR once read
      * analysis: Include libraries needed to read bytecode as well as
        implement an analysis on the LLVM IR once read.
      * compile: Include libraries needed to read/write bytecode, run
        all transforms and analyses.

There's probably several more of these but that's my $0.02 worth.

Reid.

In looking at tools, we should also look at the example programs and the
projects such as Stacker. For example, it would be nice to have a
virtual component that includes the libraries necessary for an LLVM
front end translator (source -> llvm bytecode). It would also be nice
to have a virtual component that includes the libraries necessary for an
LLVM back end target library (LLVM IR -> machine code).

What would you include in each set?

There are
probably a few other categories, for example utilities that only mess
with passes (e.g. opt, LLVM bc -> LLVM bc).

In many of these cases, you can just ask for the components you need:

   $ llvm-config --libs bcreader bcwriter scalaropts

I think this is pretty reasonable. Do you think we need to provide short aliases for all these combinations, or can we just let the user specify them manually?

"Virtual" components are quite useful, though, when (a) the exact set of libraries needed varies by platform or (b) novice users will typically link against a given set. So we need to cover both regular compiler backends and the ExecutionEngine (because the right set of libraries varies between machines) and possibly a few convenience packages.

Cheers,
Eric

> LLVM back end target library (LLVM IR -> machine code).

What would you include in each set?

I dunno. You want me to actually think about this stuff? :slight_smile:

I'd have to derive the actual set of required libraries, but I'm lacking
motivation for that task right now.

> There are
> probably a few other categories, for example utilities that only mess
> with passes (e.g. opt, LLVM bc -> LLVM bc).

In many of these cases, you can just ask for the components you need:

   $ llvm-config --libs bcreader bcwriter scalaropts

I think this is pretty reasonable.

Yup.

Do you think we need to provide
short aliases for all these combinations, or can we just let the user
specify them manually?

I think just using the "long hand" is fine for now. If it becomes
cumbersome and repetitive then we can create the "virtual
components" (shorthand) as needed.

"Virtual" components are quite useful, though, when (a) the exact set
of libraries needed varies by platform or (b) novice users will
typically link against a given set. So we need to cover both regular
compiler backends and the ExecutionEngine (because the right set of
libraries varies between machines) and possibly a few convenience
packages.

Yup. Note that I just committed a change to LibDeps.txt to reflect the
fact that ExecutionEngine now no longer depends on JIT or Interpreter
objects. This change was made by Chris today.

Reid

OK, here's my current minimalist proposal:

   backend: Either a native backend or a C backend.
   engine: Enough libs to run ExecutionEngine using either a JIT or interpreter.
   all: All LLVM libraries.

Please feel free to suggest better names. :slight_smile:

Cheers,
Eric

That's a good enough place to start. We can add more later, if desired.
The names are fine.

Reid.

Instead of 'engine', how about "jit" and "interpreter". Of course I'd think that "jit+interpreter" would also work (or something).

-Chris

Right now, you can already use the following components:

   "--libs interpreter": Include just the interpreter.
   "--libs jit native": Include the JIT and the native backend for the current platform.

If you say "engine", though, it will automatically choose between these two options for you. This seems like a useful thing to have.

For a list of all possible components, run:

   llvm-config --components

You should be able to pick any LLVM library by name.[1]

Cheers,
Eric

[1] Except "LLVMBackend.o", which clashes with the virtual "backend" component, and can only be pulled in by another library. Maybe I should rename the virtual "backend" component. :frowning:

I'm not aware of any library named LLVMBackend.o. We do, have
LLVMCBackend.o however. So, I don't think there's a name clash. But if
its less confusing, we could switch this to "target".

Reid

Ah, very cool, sounds great!

-Chris