Re: [PATCH] src/comp.c: Use constructor expressions when possible.

[Vibhav Pant]

On Fri, 2022-10-14 at 23:35 +0000, Andrea Corallo wrote:
> thanks for the patch, could you show how the generated pseudo C code
> generated with native-comp-debug = 2 changes with this patch for the
> impacted cases.

Hi Andrea,

I've attached the generated psuedo C code from compiling lisp/abbrel.el
on an Emacs build compiled with "--with-native-compilation=yes --
enable-chech-lisp-object-type". For the change made to `emit_coerce',
an example of the newly generated code can be seen in the function
`add1', line 2359:

   return (struct Lisp_Object) {.i=(struct Lisp_X *)...};

This would have earlier consisted of a new local variable being
declared, and then have `i' set to the Lisp_X value in the next line.

For `emit_limple_call_ref', any function that uses a `call_arr'
variable is initializes it in one go in one line. From line 2565:

   call_arr_4 = (struct Lisp_Object[6]) {d_reloc[(long long)5], (struct
   Lisp_Object) {.i=(struct Lisp_X *)0xe}, (struct Lisp_Object)
   {.i=(struct Lisp_X *)0x6}, (struct Lisp_Object) {.i=(struct Lisp_X
   *)0xa}, (struct Lisp_Object) {.i=(struct Lisp_X *)0x6}, slot_10};
   
    /* calling subr: funcall */
    slot_5 = freloc->R66756e63616c6c_funcall_0 ((long long)6,
   (&call_arr_4[(long long)0]));

IIUC, this would earlier have been a rather long ordeal, with every
array element that's a Lisp_Object having its own variable created
first, before being assigned to its respective array index :)

Best,
Vibhav

-- 
Vibhav Pant
vibhavp@gmail.com
GPG: 7ED1 D48C 513C A024 BE3A  785F E3FB 28CB 6AB5 9598

abbrev-2af30c9a-814198e8.c
Description: libgccjit generated psuedo C code for lisp/abbrev.el

signature.asc
Description: This is a digitally signed message part