[llvm-dev] kaleidoscope ch4 jit example regression?

[Lang Hames via llvm-dev]

Hi Nick,

It looks like we already have one: llvm/test/Examples/Kaleidoscope/Chapter4.test 

I wonder why we did not see it fail? I guess none of the builders are building with examples turned on. I will look in to that.

— Lang.

Sent from my iPad

> On Feb 21, 2019, at 9:02 AM, Nick Desaulniers <nick.desaulniers at gmail.com> wrote:
> 
> 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/8b0eabb0/attachment.html>