[jit] Avoiding hardcoding "gcc"; supporting accelerators?

[Joseph S. Myers]

On Thu, 25 Sep 2014, David Malcolm wrote:

> Should this have the $(exeext) suffix seen in Makefile.in?
>   $(target_noncanonical)-gcc-$(version)$(exeext)

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
joseph@codesourcery.com