llvm dev - Feb 2019 - kaleidoscope ch4 jit example regression?

Not yet unfortunately. I've had my head down working on a jut-linker
replacement.

Let me take a look right now...

On Mon, Feb 18, 2019 at 10:40 AM David Blaikie <dblaikie at gmail.com>
wrote:
> Ping - did this end up getting addressed?
>
> On Mon, Jan 21, 2019, 6:15 PM Lang Hames <lhames at gmail.com wrote:
>
>> Hi Nick,
>>
>> I was not aware of it, but it makes sense given the recent switch to
>> ORC2, which has different symbol resolution rules.
>>
>> I am out on vacation this week, but will take a look when I get back
and
>> see if I can restore the old behavior.
>>
>> Cheers,
>> Lang.
>>
>> Sent from my iPhone
>>
>> On Jan 20, 2019, at 2:14 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>>
>> +Lang who does JIT things
>>
>> Yeah, I can confirm my local build (using LLVM source from today) of
>> Chapter 4 behaves as you describe, and not as the documentation shows.
>> Looks like somethnig needs updating (either source or the
documentation).
>>
>> On Sun, Dec 30, 2018 at 3:28 PM Nick Desaulniers via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> https://llvm.org/docs/tutorial/LangImpl04.html has an example where
>>> the function `foo` gets redefined, and the JIT returns evaluation
of
>>> the latest definition.  I thought my code was wrong, but it seems
that
>>> the binary produced by `ninja Kaleidoscope-Ch4` has the same bug.
>>>
>>> Granted, my LLVM checkout is from Nov 3 2018 (r346062).  Is this a
known
>>> issue?
>>> ~Nick Desaulniers
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/bdbce172/attachment.html>

Ok. For the curious: The problem is that ORCv2 did away with symbol
resolvers in favor of fixed symbol tables with resolution rules intended to
match the static and dynamic linkers. That gave us a structure with which
we could coordinate concurrent compilation, but took away our ability to
arbitrarily hide old definitions (which is what we were relying on in the
tutorial).

In the short term I think we can hack around this by detecting symbol
clashes (DuplicateDefinition errors) in the KaleidoscopeJIT class and
starting a new JITDylib each time we see one: Duplicate symbols within a
dylib are not allowed, but duplicate symbols in *different* dylibs are.
Then we just search our dylibs from last to first when resolving.

In the long term we would like a way to rename or delete symbol table
entries (without deleting their underlying memory). This is probably still
a little way off: deleting / renaming in the context of concurrent
compilation is tricky.

Cheers,
Lang.

On Wed, Feb 20, 2019 at 3:20 PM Lang Hames <lhames at gmail.com> wrote:
> Not yet unfortunately. I've had my head down working on a jut-linker
> replacement.
>
> Let me take a look right now...
>
> On Mon, Feb 18, 2019 at 10:40 AM David Blaikie <dblaikie at
gmail.com> wrote:
>
>> Ping - did this end up getting addressed?
>>
>> On Mon, Jan 21, 2019, 6:15 PM Lang Hames <lhames at gmail.com wrote:
>>
>>> Hi Nick,
>>>
>>> I was not aware of it, but it makes sense given the recent switch
to
>>> ORC2, which has different symbol resolution rules.
>>>
>>> I am out on vacation this week, but will take a look when I get
back and
>>> see if I can restore the old behavior.
>>>
>>> Cheers,
>>> Lang.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 20, 2019, at 2:14 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>>>
>>> +Lang who does JIT things
>>>
>>> Yeah, I can confirm my local build (using LLVM source from today)
of
>>> Chapter 4 behaves as you describe, and not as the documentation
shows.
>>> Looks like somethnig needs updating (either source or the
documentation).
>>>
>>> On Sun, Dec 30, 2018 at 3:28 PM Nick Desaulniers via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> https://llvm.org/docs/tutorial/LangImpl04.html has an example
where
>>>> the function `foo` gets redefined, and the JIT returns
evaluation of
>>>> the latest definition.  I thought my code was wrong, but it
seems that
>>>> the binary produced by `ninja Kaleidoscope-Ch4` has the same
bug.
>>>>
>>>> Granted, my LLVM checkout is from Nov 3 2018 (r346062).  Is
this a
>>>> known issue?
>>>> ~Nick Desaulniers
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/a5511324/attachment.html>

Just saw this (while looking for another patch).
https://github.com/llvm/llvm-project/commit/ddf91af5a67bef9ca7a6f14277420e8d2dc0c66e
Thanks! (Can we add a test so this part of kaleidoscope doesn't regress
again?)

On Wed, Feb 20, 2019, 4:50 PM Lang Hames <lhames at gmail.com> wrote:
> Ok. For the curious: The problem is that ORCv2 did away with symbol
> resolvers in favor of fixed symbol tables with resolution rules intended to
> match the static and dynamic linkers. That gave us a structure with which
> we could coordinate concurrent compilation, but took away our ability to
> arbitrarily hide old definitions (which is what we were relying on in the
> tutorial).
>
> In the short term I think we can hack around this by detecting symbol
> clashes (DuplicateDefinition errors) in the KaleidoscopeJIT class and
> starting a new JITDylib each time we see one: Duplicate symbols within a
> dylib are not allowed, but duplicate symbols in *different* dylibs are.
> Then we just search our dylibs from last to first when resolving.
>
> In the long term we would like a way to rename or delete symbol table
> entries (without deleting their underlying memory). This is probably still
> a little way off: deleting / renaming in the context of concurrent
> compilation is tricky.
>
> Cheers,
> Lang.
>
> On Wed, Feb 20, 2019 at 3:20 PM Lang Hames <lhames at gmail.com>
wrote:
>
>> Not yet unfortunately. I've had my head down working on a
jut-linker
>> replacement.
>>
>> Let me take a look right now...
>>
>> On Mon, Feb 18, 2019 at 10:40 AM David Blaikie <dblaikie at
gmail.com>
>> wrote:
>>
>>> Ping - did this end up getting addressed?
>>>
>>> On Mon, Jan 21, 2019, 6:15 PM Lang Hames <lhames at gmail.com
wrote:
>>>
>>>> Hi Nick,
>>>>
>>>> I was not aware of it, but it makes sense given the recent
switch to
>>>> ORC2, which has different symbol resolution rules.
>>>>
>>>> I am out on vacation this week, but will take a look when I get
back
>>>> and see if I can restore the old behavior.
>>>>
>>>> Cheers,
>>>> Lang.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 20, 2019, at 2:14 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>>>>
>>>> +Lang who does JIT things
>>>>
>>>> Yeah, I can confirm my local build (using LLVM source from
today) of
>>>> Chapter 4 behaves as you describe, and not as the documentation
shows.
>>>> Looks like somethnig needs updating (either source or the
documentation).
>>>>
>>>> On Sun, Dec 30, 2018 at 3:28 PM Nick Desaulniers via llvm-dev
<
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> https://llvm.org/docs/tutorial/LangImpl04.html has an
example where
>>>>> the function `foo` gets redefined, and the JIT returns
evaluation of
>>>>> the latest definition.  I thought my code was wrong, but it
seems that
>>>>> the binary produced by `ninja Kaleidoscope-Ch4` has the
same bug.
>>>>>
>>>>> Granted, my LLVM checkout is from Nov 3 2018 (r346062).  Is
this a
>>>>> known issue?
>>>>> ~Nick Desaulniers
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190221/5c993e1b/attachment-0001.html>