Re: Add more supported primitives in libgccjit IR

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: gregory@heytings.org, luangruo@yahoo.com, akrl@sdf.org, eliz@gnu.org,
>>  incal@dataswamp.org, emacs-devel@gnu.org
>> Date: Mon, 21 Aug 2023 11:41:53 +0000
>> 
>> "Alfred M. Szmidt" <ams@gnu.org> writes:
>> 
>> >    > Look at data.c:arith_driver.  You'll see that it's essentially a 
>> > function 
>> >    > which dispatches the handling of its arguments depending on their 
>> > type...
>> >    >
>> >    > These integer/float/bignum types are not known at compilation time ...
>> >
>> >    This is not correct. If you have something like
>> >    (progn (setq x 1) (> x 2)), compiler is actually able to determine the
>> >    type of X at compilation time.
>> >
>> > It is absolutley correct, the Emacs compiler is not capable of doing
>> > what you are suggesting.  There are no specific functions for fixnum
>> > comparison in Emacs Lisp, nor is the Emacs Lisp compiler capable of
>> > being instructed to do such specific things.  I've been repeating this
>> > constantly now.  That is needed to make programs faster in Lisp.
>> 
>> I can see
>> 
>> /*
>>    Define a substitute for Fadd1 Fsub1.
>>    Currently expose just fixnum arithmetic.
>> */
>> 
>> static void
>> define_add1_sub1 (void)
>> 
>> in comp.c
>> 
>> So, there is some type-specific optimization going on.
>> It looks very limited though.
>
> This discussion is almost useless without Andrea on board, and you are
> using hist stale email address.  Please use the one I used here
> instead.
>
> And I really suggest that people wait for Andrea to chime in, before
> discussing code that he wrote and still maintains very actively.

Hello Eli & all,

sorry for being late to the party, I'm on holiday :)

Anyway to clarify:

Yes the native compiler does value-type inference already (this is how
the return type of functions is computed as well).

Yes one can already type hint an object to the compiler, even if this is
limited to cons and fixnums (making it generic is on my todo list).

Yes would be great IMO to extend this mechanism to function arguments
eventually as well (I might give it a go after summer?).

Yes the backend tries to inline some code when possible (ex
define_add1_sub1).

Yes we could add more of this inlining, the infrastructure is already
there but I personally had no time to work on this :(

Yes would be great to work on this benchmark driven, even if this open
the classic question of what is a set of rapresentative benchmarks.

My next activity when my time is not used by maintenance and other
activities of my life will be focused more on safetyness and correctness
I think.  I'd love to work 100% on Emacs but I must pay my bills like
everyone :)

If someone is interested on working on some of those points (or other
areas of the native compiler) I'm happy to provided help as much as I
can.

I'm sorry to observe that this conversation was fueled by someone
explaining mechanisms with no understanding of how our system works,
this makes people just loose their time :/

Best Regards

  Andrea