Add more supported primitives in libgccjit IR (was: Shrinking the C core)

[Ihor Radchenko]

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.

> Can we all stop bikeshedding over this now?  By this point, the subject
> of this thread bears absolutely no relation to the debate within.

The thread evolved to general Elisp performance discussion and this
particular branch evolved to compiler discussion. Updating the subject.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>