Lang Hames via llvm-dev
2019-Feb-20 23:20 UTC
[llvm-dev] 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>
Lang Hames via llvm-dev
2019-Feb-21 00:50 UTC
[llvm-dev] kaleidoscope ch4 jit example regression?
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>
Nick Desaulniers via llvm-dev
2019-Feb-21 17:02 UTC
[llvm-dev] kaleidoscope ch4 jit example regression?
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>