On Wed, 2022-09-28 at 14:10 +0300, Eli Zaretskii wrote: > > From: Po Lu > > Cc: Vibhav Pant > > 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