Re: Add more supported primitives in libgccjit IR

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, ams@gnu.org, incal@dataswamp.org,
>  emacs-devel@gnu.org
> Date: Mon, 21 Aug 2023 09:17:15 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Ihor Radchenko <yantar92@posteo.net> writes:
> >
> >> But let me rephrase it in other terms: what you propose will require
> >> maintaining two separate implementations of subroutines - one in C, and
> >> one specially tailored to GCC JIT psudocode. This may be doable for a
> >> small set of core primitives, but not scalable if we want to make more
> >> subroutines benefit from GGC JIT optimizations.
> >
> > I'm inclined to believe that type checks within those more complex
> > functions do not contribute so much to the runtime of most
> > native-compiled functions as the small set of arithmetic primitives do.
> 
> I am pretty sure that it depends on the specific use case.
> On average, you might be right though.
> 
> Just to get something going, I executed
> https://elpa.gnu.org/packages/elisp-benchmarks.html benchmarks and
> looked into the primitives that take significant amount of time:
> 
>      3.85%  emacs     emacs                                          [.] 
> arith_driver
>      2.62%  emacs     emacs                                          [.] Fgtr
>      2.31%  emacs     emacs                                          [.] 
> check_number_coerce_marker
>      2.24%  emacs     emacs                                          [.] Fmemq
>      2.20%  emacs     emacs                                          [.] Flss
>      1.56%  emacs     emacs                                          [.] 
> arithcompare
>      1.12%  emacs     emacs                                          [.] Faset
>      1.10%  emacs     emacs                                          [.] 
> Fcar_safe
>      0.97%  emacs     emacs                                          [.] Faref
>      0.94%  emacs     emacs                                          [.] Fplus
>      0.93%  emacs     emacs                                          [.] 
> float_arith_driver
>      0.58%  emacs     emacs                                          [.] 
> Feqlsign
> 
> We may consider directly supporting some of these functions in native
> compile libgccjit IR code to get rid of runtime type checks.

Didn't you just explained, above, how this would create separate
versions of the same code that work differently, and how that should
be avoided?