jit and cross-compilers (use and configuration).

jit and cross-compilers (use and configuration).

[Iain Sandoe]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

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?

.. 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).

thoughts?
cheers
Iain


[-- Attachment #2: 0001-configure-Disable-jit-for-cross-compilers.patch --]
[-- Type: application/octet-stream, Size: 3067 bytes --]

From 3cba4dc7a8a6d33e133354bd2846dc1f6bc7e2f1 Mon Sep 17 00:00:00 2001
From: Iain Sandoe <iain@sandoe.co.uk>
Date: Sat, 25 Jun 2022 17:56:22 +0100
Subject: [PATCH] configure: Disable jit for cross-compilers.

It is not clear how this is going to be used with a cross-compiler since
the shared library is for the host, but the code is generated for the
target.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

ChangeLog:

	* configure: Regenerate.
	* configure.ac: Disable jit for cross-compilers.
---
 configure    | 44 ++++++++++++++++++++++++++------------------
 configure.ac | 43 +++++++++++++++++++++++++------------------
 2 files changed, 51 insertions(+), 36 deletions(-)


diff --git a/configure.ac b/configure.ac
index bf416b1705b..ec608fb263e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2174,12 +2174,21 @@ if test -d ${srcdir}/gcc; then
         # Disable jit if -enable-host-shared not specified
         # but not if building for Mingw. All code in Windows
         # is position independent code (PIC).
-        case $target in
-          *mingw*) ;;
-          *)
-          case ${add_this_lang}:${language}:${host_shared} in
-            yes:jit:no)
-	           # PR jit/64780: explicitly specify --enable-host-shared
+        # Also disable if we are building a cross-compiler.        
+	case ${add_this_lang}:${language}:${is_cross_compiler}:${host_shared}:${target} in
+	  yes:jit:yes:*:*)
+	    AC_MSG_ERROR([jit is not supported for cross-compilers])
+            add_this_lang=unsupported
+            ;;
+	   all:jit:yes:*:* )
+	    AC_MSG_WARN([jit is not supported for cross-compilers])
+            add_this_lang=unsupported
+            ;;
+          yes:jit:no:*:*mingw* | all:jit:no:*:*mingw*)
+            # Windows code is always PIC, so OK.
+            ;;
+          yes:jit:no:no:*)
+	    # PR jit/64780: explicitly specify --enable-host-shared
 	    AC_MSG_ERROR([
 Enabling language "jit" requires --enable-host-shared.
 
@@ -2190,18 +2199,16 @@ If you want to build both the jit and the regular compiler, it is often
 best to do this via two separate configure/builds, in separate
 directories, to avoid imposing the performance cost of
 --enable-host-shared on the regular compiler.])
-	            ;;
-            all:jit:no)
-	      AC_MSG_WARN([--enable-host-shared required to build $language])
-              add_this_lang=unsupported
-              ;;
-            *:jit:no)
-              # Silently disable.
-              add_this_lang=unsupported
-              ;;
-	        esac
-          ;;
-        esac
+	    ;;
+          all:jit:no:no:*)
+	    AC_MSG_WARN([--enable-host-shared required to build $language])
+            add_this_lang=unsupported
+            ;;
+	  *:jit:no:no:*)
+	    # Silently disable.
+            add_this_lang=unsupported
+            ;;
+	esac
 
         # Disable a language that is unsupported by the target.
 	case "${add_this_lang}: $unsupported_languages " in
-- 
2.24.3 (Apple Git-128)

[ping] Re: jit and cross-compilers (use and configuration).

[Iain Sandoe]

Hi Dave,

Note: this does cause a build break for cross compilers with —enable-languages=all  (if the linkers for host and target have different command line options used in the build)

(it is not a serious break, one can exclude jit by manually listing all the other languages)

- nevertheless, it would be good to establish if there is a meaningful use-case for libgccjit in a cross-compiler, and if so fix the configuration - or (if no meaningful use-case) exclude it as per the patch.

thanks
Iain

> On 26 Jun 2022, at 14:06, Iain Sandoe <iain@sandoe.co.uk> 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?
> 
> .. 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).
> 
> thoughts?
> cheers
> Iain
> 
> <0001-configure-Disable-jit-for-cross-compilers.patch>

Re: jit and cross-compilers (use and configuration).

[David Malcolm]

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