Re: feature/jit-improved-type-punning 9d2a54bd8d: src/comp.c: Use libgccjit's bitcast API for type coercion, when available.

Re: feature/jit-improved-type-punning 9d2a54bd8d: src/comp.c: Use libgccjit's bitcast API for type coercion, when available.

[Po Lu]

Vibhav Pant <vibhavp@gmail.com> writes:

> branch: feature/jit-improved-type-punning
> commit 9d2a54bd8dac68b964649f7d04d04d9fa0096a62
> Author: Vibhav Pant <vibhavp@gmail.com>
> Commit: Vibhav Pant <vibhavp@gmail.com>
>
>     src/comp.c: Use libgccjit's bitcast API for type coercion, when available.
>     
> +#ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast
> +  #define gcc_jit_context_new_bitcast fn_gcc_jit_context_new_bitcast
> +#endif

This is not how we write nested defines, IIRC.  They should be written
like so:

#ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast
# define gcc_jit_context_new_bitcast fn_gcc_jit_context_new_bitcast
#endif

BTW, I don't see any code that loads this function dynamically on MS
Windows.  Isn't that needed?

> +#else /* !definedLIBGCCJIT_HAVE_gcc_jit_context_new_bitcast) */

Here, simply write:

  #else /* !LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast */

or better, no comment, since what the else corresponds to is at a glance
obvious.

Re: feature/jit-improved-type-punning 9d2a54bd8d: src/comp.c: Use libgccjit's bitcast API for type coercion, when available.

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Vibhav Pant <vibhavp@gmail.com>
> Date: Wed, 28 Sep 2022 08:22:36 +0800
> 
> BTW, I don't see any code that loads this function dynamically on MS
> Windows.  Isn't that needed?

They were present in the patch that was posted.

FWIW, I'd like to see some rationale for these changes.  Perhaps
libgccjit experts would see it immediately without any explanations,
but I'm not such an expert.  TIA.

Re: feature/jit-improved-type-punning 9d2a54bd8d: src/comp.c: Use libgccjit's bitcast API for type coercion, when available.

[Vibhav Pant]

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

On Wed, 2022-09-28 at 14:10 +0300, Eli Zaretskii wrote:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: Vibhav Pant <vibhavp@gmail.com>
> > Date: Wed, 28 Sep 2022 08:22:36 +0800
> > 
> > BTW, I don't see any code that loads this function dynamically on
> > MS
> > Windows.  Isn't that needed?
> 
> They were present in the patch that was posted.
> 
> FWIW, I'd like to see some rationale for these changes.  Perhaps
> libgccjit experts would see it immediately without any explanations,
> but I'm not such an expert.  TIA.

Type coercion in earlier versions of libgccjit was quite limited, as it
only supported casting between pointer types and integers <->
booleans/floats. Because working with lisp tagged pointers involved
converting from a Lisp_Object (which is usually a Lisp_X*) to an
integer, comp_t contained a union {uintptr_t; void *} which we would
use to emit two (cast_ptr_to_int, cast_int_to_ptr) functions before
JITting Lisp code, which would in turn initialize a union with the
input parameter, and return the required field. Combined with a 15 x 15
lookup table for every type used while compiling Lisp, all type casting
would therefore consist of emitting a call to one of these functions.

This branch uses libgccjit's new API for bitcasting between types,
which lets us skip emitting this good chunk of helper code as part of
the JIT process. Working with/extracting Lisp_Object tags in JITed code
is semantically the equivalent of a simple reinterpret_cast operation,
potentially improving optimization (although I imagine almost all calls
to these helper functions are inlined, unless native-comp-speed is 0).

Best,
Vibhav

-- 
Vibhav Pant
vibhavp@gmail.com

GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: feature/jit-improved-type-punning 9d2a54bd8d: src/comp.c: Use libgccjit's bitcast API for type coercion, when available.

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Vibhav Pant <vibhavp@gmail.com>
>> Date: Wed, 28 Sep 2022 08:22:36 +0800
>> 
>> BTW, I don't see any code that loads this function dynamically on MS
>> Windows.  Isn't that needed?
>
> They were present in the patch that was posted.
>
> FWIW, I'd like to see some rationale for these changes.  Perhaps
> libgccjit experts would see it immediately without any explanations,
> but I'm not such an expert.  TIA.

I think having explicit casts expressed to the compiler (instead of
working it around with unions as we do now) could enable the compiler
for better optimizations or maybe even some compile time gain.  Before
libgccjit did not allow for expressing it, so it's good that now we take
advantage of it when available.

Best Regards

  Andrea