From: David Malcolm <dmalcolm@redhat.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: jit and cross-compilers (use and configuration).
Date: Wed, 06 Jul 2022 18:42:54 -0400 [thread overview]
Message-ID: <3e6c287d50f36adf172a7181e0e8f8eb7fead24e.camel@redhat.com> (raw)
In-Reply-To: <BD4FD2ED-B0EA-40FD-ADB9-DF8ABC21A8F2@sandoe.co.uk>
On Sun, 2022-06-26 at 14:06 +0100, Iain Sandoe wrote:
> Hi Dave, folks,
>
> It seems to me that it is plausible that one could use the JIT in a
> heterogenous system, e.g. an x86_64-linux-host with some kind of co-
> processor which is supported as a GCC target (and therefore can be
> loaded with jit-d code) … but I’m not aware of anyone actually doing
> this?
libgccjit is horribly misnamed, in that it can also be used for ahead-
of-time compilation; I wish I'd called it libgcccodegen or somesuch.
So a more plausible use-case for cross-compilation with libgccjit is
(ahem) the non-jit case. I'd like to support this, but I have to
confess that I'm not experienced in setting up a full cross-compilation
toolchain; my cross-compilation testing of GCC has been limited to
configuring with --target and verifying by hand that sane-looking asm
is emitted.
The heterogeneous system might also be doable, but the ahead-of-time
cross-compilation seems much more important.
>
> .. is that use case even reasonable given the current implementation?
> (I guess there are invocations of the assembler etc. .. I’m not sure
> if these would work as currently implemented)
>
> ----
>
> It’s mildly inconvenient that the build for cross compilers generally
> fails for me on Darwin (reason 1 below) since I tend to configure by
> default with —enable-languages=all (and most Darwin platform versions
> default to host_shared). So I’d like to see what the best way
> forward is …..
>
> ----
>
> In the short-term there are some issues with the configuration for
> cross-compilers…
>
> 1) the values queried in gcc/jit/Make-lang.in relate to the ‘ld’ that
> is used for $target not the one used for $host.
>
> - this means that if we are on a $host with an non-binutils-ld and
> building a cross-compiler for a $target that *does* use binutils-ld,
> the configuration selects flags that do not work so that the build
> fails.
> - of course, things might fail more subtly in the case that there
> were two *different* binutils ld instances.
>
> 2) the testsuite obviously does not work.
>
> So .. one possibility is to disable jit for cross-compilers, (patch
> attached) ..
>
> … another is to find a way to fix the configuration to pick up
> suitable values for $host (although I’m not sure how much of that we
> have readily available, since usually libtool is doing that work).
FWIW I'd prefer to get it working, but I probably lack the experience
with cross-compilation to do that, alas.
Sorry that this isn't the most helpful answer
Dave
prev parent reply other threads:[~2022-07-06 22:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-26 13:06 Iain Sandoe
2022-07-06 16:11 ` [ping] " Iain Sandoe
2022-07-06 22:42 ` David Malcolm [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e6c287d50f36adf172a7181e0e8f8eb7fead24e.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=iain@sandoe.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).