- User Since
- Jun 10 2015, 8:17 AM (305 w, 6 d)
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
Oct 11 2020
Oct 8 2020
Jul 27 2020
Jul 17 2020
Jul 14 2020
May 4 2020
Abandoned in favour of @stephenneuendorffer recent list of changes.
Apr 29 2020
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.
With ninja all dependencies edges are fine, but with Makefiles it indeed still complains about missing edges to the generated headers.
small fixes and use MLIR_STATIC_LIBS
Apr 23 2020
Apr 15 2020
We do reuse the constructed pass pipeline more than once, but that is a supported configuration see -compile-twice in LLC (as an example https://reviews.llvm.org/D17712)
I am unable to reproduce the issue with this patch applied. 👍
Mar 31 2020
This is fantastic, thanks.
Mar 29 2020
Allow for manually specifying the darwin SDK version
Feb 21 2020
This is good to have as a test, but I assume that eventually we would want to have the equivalent of LLVM_LINK_LLVM_DYLIB.
@mehdi_amini and I had a conversation on discord about libMLIR.so and I think we allayed all fears that this would lock us into being stuck with a libMLIR.so if we want to eventually go down the path of including it as part of libMLIR.so
So I think we are good to go ahead with this.
Feb 20 2020
I asked in another revision, but I don't think I got an answer: what is the story for the circular dependency if we were to use MLIR in LLVM in the future? I'd be worried about adding barriers into this and I have some memory of a previous discussion that keeping a single .so would be somehow required?
Feb 19 2020
Feb 8 2020
Properly implement shared library similar to clang-shlib
Feb 2 2020
This broke cross-compilation from Linux for us, since we don't have xcodebuild/xcrun . We currently build with
Jan 28 2020
I built a shared library (D73130) and run into the case that my HasParent<FuncOp> trait failed to verify.
Jan 23 2020
Just as a note, Julia currently reverts this patch. IIRC it caused issue with gcc/mingw32 which we use for linking.
My notes from back then are fairly limited and another team member did the git bisect.
Jan 21 2020
Some additional context. We [Julia] is cross-compiling LLVM from Linux to mingw32
as part of an automatic buildsystem for our binary dependencies. The corresponding PR is https://github.com/JuliaPackaging/Yggdrasil/pull/417
Jan 17 2020
Jan 14 2020
Is there anything else to do? We (Julia) have been carrying this patch for a while.
move test and rebase
- rebase D50010