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: Emanuel Berg
Subject: Re: Add more supported primitives in libgccjit IR
Date: Mon, 28 Aug 2023 21:49:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Andrea Corallo wrote:

>> You are right, those who don't have types are those that
>> are only byte-compiled! But then why are they not
>> native-compiled as well? I think the functions inside
>> lexical let-closures, i.e.
>>
>> (let (( ... ))
>>   (defun ... ) )
>>
>> are not natively compiled.
>>
>> See the file that I yank last, none of those functions are
>> or get natively-compiled.
>
> I can't find your code now but as of today Closures is the
> last bit we don't compile.

I forgot to post it, but it doesn't matter, let-closures are
not not native-compiled, gotcha.

>>>> Maybe function that are made up of functions that have
>>>> their types inferred also get their types inferred ...
>>>
>>> Of course they are typed as well, but we can use the types
>>> of the called functions for propagations as they can be
>>> redefined in every moment.
>>
>> We can?
>
> Apologies for the typo, wanted to write _can't_.

Are they used for propagations at native-compile time?
Because how else is the function type inferred?

And is it true that the type inferred for a particular
function is only guaranteed to hold at native-compile time, if
that is when it happens?

Because if we have f(x) = a(b(c(x))) and a, b, and c can be
redefined at run time, how can we know the type of f at
run time?

Without again do native-compile of c, b, a, and f that is?

Are there functions to do inference so I can try them on
random functions?

BTW I like it how the type is expressed in Lisp B)

-- 
underground experts united
https://dataswamp.org/~incal




reply via email to

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