Fri, Jul 23
Sun, Jul 18
Sat, Jul 17
@loladiro does this impact us? Julia does support running under valgrind, see https://docs.julialang.org/en/v1/devdocs/valgrind/,
and IIRC that extends to JIT'ed code.
Fri, Jul 16
Thu, Jul 15
Update test for adding dependencies and clang-format
Mon, Jul 12
Apply changes from lhames
Sun, Jul 11
Regarding the MaterializationResponsibility API: it would be good to add the addDependencies and addDependenciesForAll methods. These declare dependencies for each materializing symbol so that ORC can track them in its dependence graph, which in turn ensures that lookups remain safe regardless of what threads the symbols are being materialized on. These methods are an essential part of the MaterializationResponsibility API.
Address part of the review
Fri, Jul 2
add first draft of docs and unit test for MaterializationResponisibility
Thu, Jul 1
clang-format and rebase
Add comment and clang-format
Address review comments
Wed, Jun 30
Sun, Jun 27
Sat, Jun 26
Create separate MaterializationUnit's
Fri, Jun 25
Jun 23 2021
Use IRLayer::emit instead of LLJIT::add
@lhames this currently fails with
Jun 21 2021
Jun 17 2021
May 14 2021
May 10 2021
May 7 2021
Feb 16 2021
Jan 19 2021
That does seem to indeed fix all the remaining issues with Float16 that the Julia testsuite covers :)
Abandoned in favour of D94980
Jan 15 2021
Good to go from the Julia side.
Jan 5 2021
Dec 16 2020
This fixed a whole set of bugs for us but it also seems to have caused a regression.
Dec 9 2020
Looks good from the Julia side, this does indeed fix the upstream bug. Thanks @nemanjai!
Dec 7 2020
Rebase commit onto main
Thanks! I rebased the PR and landed it.
Dec 6 2020
Bump for review. We (Julia) have been carrying this one for a while.
Nov 27 2020
Nov 23 2020
@reames I think you are the right person to review this. Any objections?
We have been carrying this on the Julia side. I can rebase this on master if that would help (LLVM 11 version is available here https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-11-D75072-SCEV-add-type.patch)
Well, I've tested it and it doesn't seem to break anything for us (Gentoo) but I don't really understand why you'd have a different install dir for LLVM and Clang.
Nov 6 2020
In favor of https://reviews.llvm.org/D90969
Nov 3 2020
Looks good from my side. @lhames should sign off though.
Oct 19 2020
It is questionable for a downstream project to parse and interpret LLVM internal options directly. It should at least to have a -mllvm or --plugin-opt= prefix.
Oct 18 2020
Yeah, I basically copy-and-pasted the original implementation, since we are indeed parsing this from the environment. https://github.com/JuliaLang/julia/pull/38092/commits/72c2136dfad7a535dba563c0f37f3c70da5558a2
@MaskRay why was it necessary to delete this? It is used by downstream projects (like Julia). I agree that it isn't too much hassle to implement, but every tool that uses LLVM as a library will have to write a version themselves.
Oct 12 2020
I think this can be very noisy as the number of relocations can be very large.
Oct 11 2020
Oct 8 2020
Jul 27 2020
I am interested in continuing this work and have a patch in progress based on the current available one here. Should I post the new patch here or under a new bug?
Jul 17 2020
Jul 14 2020
May 4 2020
Abandoned in favour of @stephenneuendorffer recent list of changes.
Apr 29 2020
@vchuravy, What's your plan with this patch? I think this should land and I've started building on top of it.
Right the issue for is that LLVM6 used to accept and compile it without issue:
Apr 24 2020
Does this get us closer to fixing LLVM_LINK_LLVM_DYLIB?
Ultimately, the solution may be to just generate all the headers before building everything else, which means that all mlir libraries would have a dependence on all IncGen targets. That isn't great, but I think it's better than the fix proposed in this review.