Re: gcc11: enable libgccjit
On 2023/11/07 11:02:26 +0100, Jeremie Courreges-Anglas wrote: > On Mon, Nov 06 2023, Omar Polo wrote: > > Hello, > > > > Admittedly, this is mostly for Emacs. As such, I don't think it makes > > sense to enable it on gcc8 too (emacs doesn't seem like that libgccjit). > > Indeed it needs a version recent enough. > > > Anyway, my idea would be to first enable it in the gcc11 port and > > disable it in emacs so that it's not picked up automatically, see how it > > goes and then start to see if/how enable support in the emacs port. > > No need to explicitely disable in the emacs port for now, as it isn't > enabled by default. To be future-proof, you may go ahead and > add --without-native-compilation if you want to. oh, sorry, I thought it was enabled by default if found. > > Building libgccjit requires the whole compiler to be compile with > > --enable-hosh-shared: > > > > : Specify that the host code should be built into position-independent > > : machine code (with -fPIC), allowing it to be used within shared > > : libraries, but yielding a slightly slower compiler. > > > > I don't know how much 'slightly' amounts to, but other repositories are > > building libgccjit separateadly to avoid using --enable-host-shared on > > gcc. > > We're using PIE on most archs so I /suspect/ it doesn't change much. > A REVISION bump of all subpackages seems appropriate though. That's what I was thinking too, and why I wasn't particularly worried of building libgccjit separateadly as other repositories are doing. > > Other than that, the only point worth noticing is that ensuring that > > libgccjit has the right version set by the ports infrastructure and that > > no symlinks are installed requires some fiddling. > > There are more things to care about: we're using lang/gcc/8 by default > so you can't really depend on lang/gcc/11 subpackages in the ports > infrastructure, as long as we're not moving the whole tree to > lang/gcc/11 (or newer). Technically you could, if libgccjit was > standalone, but with your diff it depends on lang/gcc/11,-main (needs > RUN_DEPEND-jit = # blank). Ops, right, I forgot to empty the run depeds of -jit. The library itself should be standalone (it's my understanding so far at least) > Also the emacs build uses of -lgcc so you'd > need a dep on gcc-libs-11, and that would be a blocker since it > conflicts with lang/gcc/8,-libs. Here I'm not following, in my build log I see only -lgccjit > > Ah, also note that this needs makeinfo.c rev. 1.9, otherwise base > > makeinfo crashes handling libgccjit.info (due to an off-by-one spotted > > by otto' malloc ;-) > > > > I've been running Emacs with this enabled and, while I haven't noticed > > any significant difference in my setup, it hasn't broke yet :) > > But what benefits does it bring? Moar faster when loading > user-controlled .el files? Significantly faster than byte-compiled .elc > files? To be honest I can't really tell. In my emacs setup (that is pretty barebone) I haven't noticed any differences. I've seen great things about how this native compilation speeds up emacs in general (so, yes, speed!). To notice I guess one has to use relatively big packages like org, magit, etc. > > Even if it's called "jit", emacs actually uses it to compile lisp to > > shared objects in a per-user cache which are then loaded. For e.g. this > > is the compiled version of vc-got.el: > > > > % file -b .emacs.d/eln-cache/29.1-09cbcfb6/vc-got-e9cf3f4d-5edd1876.eln > > ELF 64-bit LSB shared object, x86-64, version 1 > > I feel uneasy at bringing back more low level stuff to emacs but it > looks like its upstream maintainers like pain. This directory full of > binary files under .emacs.d looks like a can of worms ready to blow up > when upgrading across major versions of emacs / the system, or when > you're syncing your .emacs.d directory across machines. > > I'm frankly not sold on the idea. AFAICS the caches are per emacs version, so upgrading (or downgrading) across emacs versions should be supported. I haven't thought about what happens across system upgrades or any other kind of system changes. Part of me would expect no issues, since these eln files don't link to other libraries (neither libc), as they're "just" the native compilation of lisp bits that call emacs functions, but the devil is in the details and I admittedly haven't studied in the details how this works. I was mostly curious to give it (another) try, especially after someone in the fediverse prodded me into looking at this again.
Re: gcc11: enable libgccjit
On Mon, Nov 06 2023, Omar Polo wrote: > Hello, > > Admittedly, this is mostly for Emacs. As such, I don't think it makes > sense to enable it on gcc8 too (emacs doesn't seem like that libgccjit). Indeed it needs a version recent enough. > Anyway, my idea would be to first enable it in the gcc11 port and > disable it in emacs so that it's not picked up automatically, see how it > goes and then start to see if/how enable support in the emacs port. No need to explicitely disable in the emacs port for now, as it isn't enabled by default. To be future-proof, you may go ahead and add --without-native-compilation if you want to. > Building libgccjit requires the whole compiler to be compile with > --enable-hosh-shared: > > : Specify that the host code should be built into position-independent > : machine code (with -fPIC), allowing it to be used within shared > : libraries, but yielding a slightly slower compiler. > > I don't know how much 'slightly' amounts to, but other repositories are > building libgccjit separateadly to avoid using --enable-host-shared on > gcc. We're using PIE on most archs so I /suspect/ it doesn't change much. A REVISION bump of all subpackages seems appropriate though. > Other than that, the only point worth noticing is that ensuring that > libgccjit has the right version set by the ports infrastructure and that > no symlinks are installed requires some fiddling. There are more things to care about: we're using lang/gcc/8 by default so you can't really depend on lang/gcc/11 subpackages in the ports infrastructure, as long as we're not moving the whole tree to lang/gcc/11 (or newer). Technically you could, if libgccjit was standalone, but with your diff it depends on lang/gcc/11,-main (needs RUN_DEPEND-jit = # blank). Also the emacs build uses of -lgcc so you'd need a dep on gcc-libs-11, and that would be a blocker since it conflicts with lang/gcc/8,-libs. > Ah, also note that this needs makeinfo.c rev. 1.9, otherwise base > makeinfo crashes handling libgccjit.info (due to an off-by-one spotted > by otto' malloc ;-) > > I've been running Emacs with this enabled and, while I haven't noticed > any significant difference in my setup, it hasn't broke yet :) But what benefits does it bring? Moar faster when loading user-controlled .el files? Significantly faster than byte-compiled .elc files? > Even if it's called "jit", emacs actually uses it to compile lisp to > shared objects in a per-user cache which are then loaded. For e.g. this > is the compiled version of vc-got.el: > > % file -b .emacs.d/eln-cache/29.1-09cbcfb6/vc-got-e9cf3f4d-5edd1876.eln > ELF 64-bit LSB shared object, x86-64, version 1 I feel uneasy at bringing back more low level stuff to emacs but it looks like its upstream maintainers like pain. This directory full of binary files under .emacs.d looks like a can of worms ready to blow up when upgrading across major versions of emacs / the system, or when you're syncing your .emacs.d directory across machines. I'm frankly not sold on the idea. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
gcc11: enable libgccjit
Hello,
Admittedly, this is mostly for Emacs. As such, I don't think it makes
sense to enable it on gcc8 too (emacs doesn't seem like that libgccjit).
Anyway, my idea would be to first enable it in the gcc11 port and
disable it in emacs so that it's not picked up automatically, see how it
goes and then start to see if/how enable support in the emacs port.
Building libgccjit requires the whole compiler to be compile with
--enable-hosh-shared:
: Specify that the host code should be built into position-independent
: machine code (with -fPIC), allowing it to be used within shared
: libraries, but yielding a slightly slower compiler.
I don't know how much 'slightly' amounts to, but other repositories are
building libgccjit separateadly to avoid using --enable-host-shared on
gcc.
Other than that, the only point worth noticing is that ensuring that
libgccjit has the right version set by the ports infrastructure and that
no symlinks are installed requires some fiddling.
Ah, also note that this needs makeinfo.c rev. 1.9, otherwise base
makeinfo crashes handling libgccjit.info (due to an off-by-one spotted
by otto' malloc ;-)
I've been running Emacs with this enabled and, while I haven't noticed
any significant difference in my setup, it hasn't broke yet :)
Even if it's called "jit", emacs actually uses it to compile lisp to
shared objects in a per-user cache which are then loaded. For e.g. this
is the compiled version of vc-got.el:
% file -b .emacs.d/eln-cache/29.1-09cbcfb6/vc-got-e9cf3f4d-5edd1876.eln
ELF 64-bit LSB shared object, x86-64, version 1
P.S.: how much of "you shouldn't skip bootstrap unless you know what
you're doing" is true for 'normal' builds like these? I've used
FLAVOR='no_ada full' however.
Index: DESCR-jit
===
RCS file: DESCR-jit
diff -N DESCR-jit
--- /dev/null 1 Jan 1970 00:00:00 -
+++ DESCR-jit 2 Nov 2023 14:57:32 -
@@ -0,0 +1,12 @@
+The GNU Compiler Collection (GCC) includes front ends for C, C++,
+Objective-C, Fortran, Java, and Ada, as well as libraries for these
+languages (libstdc++, libgcj,...).
+
+GCC development is a part of the GNU Project and uses an open
+development environment. Its supports many other platforms in order to
+foster a world-class optimizing compiler, to attract a larger team of
+developers, to ensure that GCC and the GNU system work on multiple
+architectures and diverse environments, and to more thoroughly test and
+extend the features of GCC.
+
+This package contains the JIT compiler.
Index: Makefile.inc
===
RCS file: /home/cvs/ports/lang/gcc/Makefile.inc,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.inc
--- Makefile.inc11 Mar 2022 19:28:58 - 1.20
+++ Makefile.inc2 Nov 2023 14:57:00 -
@@ -16,6 +16,7 @@ COMMENT-objc= ${COM}: obj C compiler
COMMENT-ada= ${COM}: Ada compiler
COMMENT-go=${COM}: Go compiler
COMMENT-dlang= ${COM}: D compiler
+COMMENT-jit= ${COM}: JIT compiler
PKGNAME?= gcc-${FULL_PKGVERSION}
PKGNAME-libs?= gcc-libs-${FULL_PKGVERSION}
@@ -26,6 +27,7 @@ PKGNAME-objc?=gobjc-${FULL_PKGVERSION}
PKGNAME-ada?= gnat-${FULL_PKGVERSION}
PKGNAME-go?= gccgo-${FULL_PKGVERSION}
PKGNAME-dlang?=gdc-${FULL_PKGVERSION}
+PKGNAME-jit?= libgccjit-${FULL_PKGVERSION}
DESCR-main ?= ${PORTSDIR}/lang/gcc/DESCR
DESCR-libs ?= ${PORTSDIR}/lang/gcc/DESCR-libs
@@ -36,6 +38,7 @@ DESCR-objc ?= ${PORTSDIR}/lang/gcc/DESCR
DESCR-ada ?= ${PORTSDIR}/lang/gcc/DESCR-ada
DESCR-go ?=${PORTSDIR}/lang/gcc/DESCR-go
DESCR-dlang ?= ${PORTSDIR}/lang/gcc/DESCR-dlang
+DESCR-jit ?= ${PORTSDIR}/lang/gcc/DESCR-jit
HOMEPAGE?= https://gcc.gnu.org/
Index: 11/Makefile
===
RCS file: /home/cvs/ports/lang/gcc/11/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- 11/Makefile 25 Sep 2023 17:07:31 - 1.22
+++ 11/Makefile 3 Nov 2023 15:56:23 -
@@ -18,7 +18,7 @@ USE_NOEXECONLY = Yes
V = 11.2.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
-REVISION = 9
+REVISION = 10
ADASTRAP-amd64 = adastrap-amd64-$V-3.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
@@ -35,6 +35,7 @@ PKGNAME-f95 = g95-${FULL_PKGVERSION}
PKGNAME-objc = gobjc-${FULL_PKGVERSION}
PKGNAME-ada = gnat-${FULL_PKGVERSION}
PKGNAME-dlang = gdc-${FULL_PKGVERSION}
+PKGNAME-jit = libgccjit-${FULL_PKGVERSION}
PKGSPEC-main = gcc->=11,<12
SHARED_LIBS = estdc++ 20.0 \
@@ -48,12 +49,13 @@ SHARED_LIBS = estdc++ 20.0 \
cc1plugin 2.0 \
cp1plugin 1.0 \
gphobos 0.0 \
- gdruntime 0.0
+ gdruntime 0.0 \
+ gccjit 0.0
PSEUDO_FLAVORS = no_ada full
FLAVOR ?=
-MULTI_PACKAGES = -main -libs -f95 -objc -c++ -ada -dlang
+MULTI_PACKAGES = -main -libs
