[jit] Avoiding hardcoding "gcc"; supporting accelerators?
Joseph S. Myers
Fri Sep 26 21:55:00 GMT 2014
On Thu, 25 Sep 2014, David Malcolm wrote:
> Should this have the $(exeext) suffix seen in Makefile.in?
Depends on whether that's needed for the pex code to find it.
> As for (B), would it make sense to "bake in" the path to the binary into
> the pex invocation, and hence to turn off PEX_SEARCH? If so, presumably
> I need to somehow expand the Makefile's value of $(bindir) into
> internal-api.c, right? (I tried this in configure.ac, but merely got
> "$(exec_prefix)/bin" iirc).
An installation must be relocatable. Thus, you can't just hardcode
looking in the configured prefix; you'd need to locate it relative to
libgccjit.so in some way (i.e. using make_relative_prefix, but I don't
know offhand how libgccjit.so would locate itself).
> A better long-term approach to this would be to extract the spec
> machinery from gcc.c (perhaps into a "libdriver.a"?) and run it directly
> from the jit library - but that's a rather involved patch, I suspect.
And you'd still need libgccjit.so to locate itself for proper
relocatability in finding other pieces such as assembler and linker.
> I wonder if the appropriate approach here is to have a single library
> with multiple plugin backends e.g. one for the CPU, one for each GPU
> family, with the ability to load multiple "backends" at once.
If you can get that working, sure.
> Unfortunately, "backend" is horribly overloaded here - I mean basically
> all of gcc here, everything other than the libgccjit.h API seen by
> client code.
(Though preferably as much as possible could be shared, i.e. properly
define the parts of GCC that need building separately for each target and
limit them as much as possible. Joern's multi-target patches from 2010
that selectively built parts of GCC using namespaces while sharing others
without an obvious clear separation seemed very fragile. For something
robust you either build everything separately for each target, or have a
well-defined separation between bits needing building separately and bits
that can be built once and ways to avoid non-obvious target dependencies
in bits built once.)
Joseph S. Myers
More information about the Gcc-patches