[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
- Re: Add more supported primitives in libgccjit IR, (continued)
- Re: Add more supported primitives in libgccjit IR, Ihor Radchenko, 2023/08/23
- Re: Add more supported primitives in libgccjit IR, Andrea Corallo, 2023/08/25
- Re: Add more supported primitives in libgccjit IR, Ihor Radchenko, 2023/08/25
- Re: Add more supported primitives in libgccjit IR, Andrea Corallo, 2023/08/25
- Re: Add more supported primitives in libgccjit IR, Ihor Radchenko, 2023/08/26
- Re: Add more supported primitives in libgccjit IR, Emanuel Berg, 2023/08/27
- Re: Add more supported primitives in libgccjit IR, Emanuel Berg, 2023/08/27
- Re: Add more supported primitives in libgccjit IR, Andrea Corallo, 2023/08/27
- Re: Add more supported primitives in libgccjit IR, Emanuel Berg, 2023/08/27
- Re: Add more supported primitives in libgccjit IR, Andrea Corallo, 2023/08/28
- Re: Add more supported primitives in libgccjit IR,
Emanuel Berg <=
- Re: Add more supported primitives in libgccjit IR, Emanuel Berg, 2023/08/26
- Re: Add more supported primitives in libgccjit IR, Ihor Radchenko, 2023/08/26
- Re: Add more supported primitives in libgccjit IR, Emanuel Berg, 2023/08/26
- Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core), Gregory Heytings, 2023/08/21
- Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core), Ihor Radchenko, 2023/08/21
- Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core), Gregory Heytings, 2023/08/21
- Re: Add more supported primitives in libgccjit IR, Manuel Giraud, 2023/08/21
- Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core), Alfred M. Szmidt, 2023/08/21
- Re: Add more supported primitives in libgccjit IR, Eli Zaretskii, 2023/08/21
- Re: Add more supported primitives in libgccjit IR, Ihor Radchenko, 2023/08/21