emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add more supported primitives in libgccjit IR


From: Ihor Radchenko
Subject: Re: Add more supported primitives in libgccjit IR
Date: Fri, 25 Aug 2023 11:06:56 +0000

Andrea Corallo <acorallo@gnu.org> writes:

>> Do I understand correctly that value-type inference is still extremely
>> limited?
>
> Why?

Because when I tried to check if there is type optimization, I ran into
that `lisp' + `listp' call that was not optimized.

Are there other known instances of such missing inference?

> If we could have a bug report for this I can work on it as soon as I get
> time.

Done. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65527

>> Do you have any comment on the problem with having multiple parallel
>> implementations of the same subroutine?
>
> It's not nice but if justified by performance for few core functions I
> think is acceptable.

I just thought if we could have this native compilation-specific
implementations done in Elisp instead of C. AFAIU, it would then be
inlined as needed just as a part of normal nativecomp optimizations. But
the main question if it could be possible to retain C performance in the
generic case when argument values cannot be inferred ahead of time.

>> Is there any detailed information about the format of native compile
>> debug output?
>
> Not so far sorry, that's an internal dump format, do you have any
> specific question?
> ...
> The compiler performs a series of transformations on the code, those are
> called "passes".  In the *Native-compile-Log* you can see the dump of
> the code for each function being compiled in the current intermendiate
> rapresentation.  You'll see that the first intermediate rapresentation
> is LAP, most of the following passes are dumped in LIMPLE.

I have no questions about passes - they are described in your paper.
Though it would be nice to put a reference to it in log buffer, manual,
or even share the paper together with Emacs sources.

However, the internal dump format prevents more detailed understanding.
For example, there is no easy way for other people to figure out what
goes wrong during the optimization passes without knowing the dump
format. Having an example annotated debug output would be helpful to
make things more clear.

-- 
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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]