- User Since
- Jun 10 2015, 8:17 AM (279 w, 5 d)
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.
Sun, Oct 18
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.
Mon, Oct 12
Sun, Oct 11
Thu, Oct 8
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
Dec 22 2019
Dec 21 2019
Dec 18 2019
- reduce test
- update test
Dec 16 2019
Dec 14 2019
Sorry that it took so long for me to finish this.
- update aaccording to comments
Dec 13 2019
Nov 30 2019
- fix AS in anyref testfile
Nov 28 2019
restore previous changes
support old DL modules
Nov 27 2019
Rebased onto current master and added an initial test. (I will start adding more as I start integrating this with the rest of the toolchain)
- add test for passing anyref through a function
- fix wrong name for funcref
- fixes and formatting
- fix error message
Oct 2 2019
- change anyref AS to 256
- fix some comments and address nit
Keno has asked me to take this over for him and I will work on getting this into shape so that it can get landed.
Sep 27 2019
Aug 23 2019
Aug 20 2019
Thanks Martin for the quick response and fix. My minimal test-case works and I am in the progress of testing our full build.
Aug 18 2019
This broke Julia downstream (https://github.com/JuliaLang/julia/pull/32712#issuecomment-521206577). In Julia we emit JIT'ed code on MINGW as ELF+Static relocation model (https://github.com/JuliaLang/julia/blob/be3b04b29654a463b4dc899a228b5f53e862cdde/src/codegen.cpp#L7653-L7669), due us having issues with COFF support in RuntimeDyld.
May 5 2019
Jul 23 2018
It indeed does! Thanks!