Marc:
I was just told that the development version of gcc:
heine:~/programs/gcc/gcc-mainline> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --disable-multilib --enable-languages=c --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.0 20240819 (experimental) (GCC)
supports a version of musttail with documentation source ============ @cindex @code{musttail} statement attribute @item musttail
The @code{gnu::musttail} or @code{clang::musttail} attribute can be applied to a @code{return} statement with a return-value expression that is a function call. It asserts that the call must be a tail call that does not allocate extra stack space, so it is safe to use tail recursion to implement long running loops.
@smallexample [[gnu::musttail]] return foo(); @end smallexample
If the compiler cannot generate a @code{musttail} tail call it will report an error. On some targets tail calls may never be supported. Tail calls cannot reference locals in memory, which may affect builds without optimization when passing small structures, or passing or returning large structures. Enabling @option{-O1} or @option{-O2} can improve the success of tail calls. @end table ============
Must I change any configuration or header files to try the musttail attribute of gcc?
Brad
Afficher les réponses par date
Hi Brad. It is nice to see that support for tail-calls is improving in GCC. If you want to test this out, here are the lines of gambit.h.in that define the ___PROPER_TAIL_CALL C macro that is used to indicate that a call must be a tail call:
#if __has_attribute(musttail) #define ___PROPER_TAIL_CALL(call) __attribute__((musttail)) return call #else #if defined(___TRUST_C_TCO) #define ___PROPER_TAIL_CALL(call) return call #endif #endif
The __has_attribute(musttail) will be true for clang versions that have the musttail attribute. Something similar should be used to detect the feature on GCC (I’m not sure this test also works for GCC as is).
What is also needed is some testing on various architectures to see which targets (x86, arm, etc) support the attribute. This knowledge can then be used in conditional expansions in the gambit.h.in file to use musttail only on those targets where it is known to work. The fallback when the target is not known to support musttail is to use a trampoline, which has worked for many years with acceptable performance.
Marc
On Aug 20, 2024, at 6:54 PM, Bradley Lucier lucier@purdue.edu wrote:
Must I change any configuration or header files to try the musttail attribute of gcc?
Brad
On 8/20/24 9:38 PM, Marc Feeley wrote:
#if __has_attribute(musttail) #define ___PROPER_TAIL_CALL(call) __attribute__((musttail)) return call #else #if defined(___TRUST_C_TCO) #define ___PROPER_TAIL_CALL(call) return call #endif #endif
OK, here's how I understand things. I could be wrong, of course.
GCC 15.0.0 (developmental mainline)
1. __has_attribute(musttail) is true.
2. Does not currently support the __attribute__((musttail)) notation, so if you need to bootstrap mainline Gambit, which first checks out and builds 4.9.5 release before building GitHub head, you can't use current mainline gcc. I'll ask the GCC folks whether __attribute__((musttail)) will be supported.
3. Does support [[gnu::musttail]] and [[clang::musttail]] and they appear to be synonyms.
Clang 14.0.0 (what I have on my Ubuntu 22.04 box):
1. __has_attribute(musttail) is true.
2. Supports the __attribute__((musttail)) notation.
3. If you want to use the [[clang::musttail]] notation, you must set -std=c2x or something similar on the command line.
So by fiddling around with include/gambit.h by hand, I got current Gambit head to build with [[clang:musttail]] on both GCC mainline and clang 14.0.0. make check passes with GCC mainline.
The clang build with -std=c2x has failures in make check of the following form:
------------ TEST 6 (link and execute the code generated) rm -f mix_.c mix.o mix_.o mix ../gsc/gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm ../gsc/gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -f -warnings -o mix -exe mix.c In file included from mix.c:631: /home/lucier/programs/gambit/gambit/include/gambit.h:9519:5: error: unknown type name 'sigset_t'; did you mean '__sigset_t'? sigset_t sigset[3]; ^~~~~~~~ __sigset_t /usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h:8:3: note: '__sigset_t' declared here } __sigset_t; ^ 1 error generated. *** ERROR IN ##main -- target compilation or link failed while compiling "mix.c" make[1]: [makefile:149: test6] Error 70 (ignored)
Brad
Thanks for doing the grunt work of testing musttail on GNU gcc and clang.
I think your changes to gambit.h.in would be better expressed as 2 separate cases for GNU gcc and clang rather than trying to find a syntax that is supported by both (for example it is forcing the use of -std=c2x and that is not a requirement we want to introduce). The case for clang can stay as it is currently. We just need the syntax for GNU gcc. Is it
[[musttail]] return foo(…);
?
Marc
On Aug 24, 2024, at 9:46 PM, Bradley Lucier lucier@purdue.edu wrote:
On 8/20/24 9:38 PM, Marc Feeley wrote:
#if __has_attribute(musttail) #define ___PROPER_TAIL_CALL(call) __attribute__((musttail)) return call #else #if defined(___TRUST_C_TCO) #define ___PROPER_TAIL_CALL(call) return call #endif #endif
OK, here's how I understand things. I could be wrong, of course.
GCC 15.0.0 (developmental mainline)
__has_attribute(musttail) is true.
Does not currently support the __attribute__((musttail)) notation, so if you need to bootstrap mainline Gambit, which first checks out and builds 4.9.5 release before building GitHub head, you can't use current mainline gcc. I'll ask the GCC folks whether __attribute__((musttail)) will be supported.
Does support [[gnu::musttail]] and [[clang::musttail]] and they appear to be synonyms.
Clang 14.0.0 (what I have on my Ubuntu 22.04 box):
__has_attribute(musttail) is true.
Supports the __attribute__((musttail)) notation.
If you want to use the [[clang::musttail]] notation, you must set -std=c2x or something similar on the command line.
So by fiddling around with include/gambit.h by hand, I got current Gambit head to build with [[clang:musttail]] on both GCC mainline and clang 14.0.0. make check passes with GCC mainline.
The clang build with -std=c2x has failures in make check of the following form:
------------ TEST 6 (link and execute the code generated) rm -f mix_.c mix.o mix_.o mix ../gsc/gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c mix.scm ../gsc/gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -f -warnings -o mix -exe mix.c In file included from mix.c:631: /home/lucier/programs/gambit/gambit/include/gambit.h:9519:5: error: unknown type name 'sigset_t'; did you mean '__sigset_t'? sigset_t sigset[3]; ^~~~~~~~ __sigset_t /usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h:8:3: note: '__sigset_t' declared here } __sigset_t; ^ 1 error generated. *** ERROR IN ##main -- target compilation or link failed while compiling "mix.c" make[1]: [makefile:149: test6] Error 70 (ignored)
Brad
This is the notation.
On Aug 24, 2024, at 22:51, Marc Feeley feeley@iro.umontreal.ca wrote:
- Does support [[gnu::musttail]] and [[clang::musttail]] and they appear to be synonyms.
Really? I find it strange that on GNU gcc you have to say “gnu” in [[gnu::musttail]].
BTW having good C tail call support opens the door to a faster protocol to jump from one host function to another. Currently the only parameter of a host function is the processor state that contains many things including the state of the GVM registers and the “pc”. It would be interesting to explore passing the GVM registers and the pc in the host function parameters. That should be faster than the current caching mechanism that has to read the processor state at the entry of the host function, and write the processor state at the end of the host function.
Marc
On Aug 24, 2024, at 11:01 PM, Lucier, Bradley J lucier@purdue.edu wrote:
This is the notation.
On Aug 24, 2024, at 22:51, Marc Feeley feeley@iro.umontreal.ca wrote:
- Does support [[gnu::musttail]] and [[clang::musttail]] and they appear to be synonyms.
On 8/25/24 9:45 AM, Marc Feeley wrote:
Really? I find it strange that on GNU gcc you have to say “gnu” in [[gnu::musttail]].
The current GCC mainline does not accept [[musttail]] as an attribute, e.g.,:
_num.c: In function '___H__23__23_random_2d_source_2d_make_2d_integers': _num.c:106590:1: warning: 'musttail' attribute ignored [-Wattributes] 106590 | ___END_P_COD
It does accept [[clang::musttail]], seemingly with the same meaning as [[gnu::musttail]]. Perhaps it doesn't accept [[musttail]] because musttail is not a C standard attribute.
This is all very new GCC machinery, added in July. It seems to have stabilized, but I don't know what final form it will take.
Brad