Find versioned versions of LLVM tools
Since it has become more widely know that the LLVM developers often make breaking changes to the IR language between releases, some Linu distributions (eg Debain and hence Ubuntu) have started doing multi-version LLVM installs.
For instance on Debian, the llvm-3.6 programs are installed in /usr/lib/llvm-3.6/bin as llc and opt.
I propose that the configure.ac and aclocal.m4 configuration goop be modified to look for llc and opt in these versioned /usr/lib/llvm-X.Y locations. I'm also willing to do the hard yards on implementing this if people think its a good idea.
This can be seen as a step along the way to more stringent LLVM versioning requirements.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
Activity
added LLVM backend Tbug Trac import labels
This should already work. If it doesn't, than that's indeed a bug. See commit 1dfab7a8
Author: Thomas Miedema <thomasmiedema@gmail.com> Date: Mon Mar 2 11:09:33 2015 -0600 Fix detection of llvm-x.x Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439@thomie It doesn't work now, because on my machine it picks
/usr/bin/llc(which is actually a symlink to/usr/lib/llvm-3.5/bin/llc) before it picks/usr/lib/llvm-3.6/bin/llc. I can't remove llvm-3.5 because I have other tools that rely on it.If people think its a good idea, I would make the configure script check for a specific version of the llvm tools (currently 3.6 because thats all that seems to work currently). With this versioned check, when we move to another version of LLVM there should be one single change to configure.ac to make it check for the new version.
On my Debian system there is also
/usr/bin/llc-3.xwhich is a symlink to/usr/lib/llvm-3.x/bin/llc. If GHC requires LLVM 3.6, for instance, wouldn't it be best to look forllc-3.6in the$PATH, rather than specifically/usr/lib/llvm-3.6/bin/llc? Then it would also work if the user installedllc-3.6other than through their package manager (e.g., in~/bin).Maybe this is what you were suggesting in ticket:10170#comment:97426, not sure.
@rwbarton Yes, it should look for a versioned
/usr/lib/llc-X.Ybut also accept/usr/lib/llvm-3.6/bin/llc(I'm pretty sure the versioned symlinks in/usr/bin/are managed by the Debianalternativessystem and therefore optional). More importantly configure should fail if whatever version ofllcit finds isn't the currently blessed version.@thomie Unfortunately, I think that
FIND_LLVMmacro will need to grow, not disappear.More importantly configure should fail if whatever version of llc it finds isn't the currently blessed version.
Right.
Yes, it should look for a versioned
/usr/lib/llc-X.Ybut also accept/usr/lib/llvm-3.6/bin/llcLet me rephrase what I meant. Hard-coding knowledge of the directory
/usr/lib/llvm-3.6/bininto ghc's autoconf is wrong because (in my estimation) the fact thatllc-3.6is a symlink to/usr/lib/llvm-3.6/bin/llcis an implementation detail of the Debianllvm-3.6package and the executable may be (and is) located elsewhere on other distributions. The public interface ofllvm-3.6(on Debian and hopefully on other distributions) is that it providesllc-3.6on the standard$PATH.@thomie That would work for some cases, but imo, if
llc-3.6does not exist, the configure script should still check to see ifllcis the required version.@rwbarton I agree about not looking for
/usr/lib/llvm-3.6/bin/llc. That was a silly idea.@nomeata That may be true, but we still need to fix this for people compiling from git.
I've been doing some hacking on this and here is my current solution (for now
X.Yis3.6):- The configure script should check for
llc-X.Yandopt-X.Y*before* it checks for plainllcandopt. - Only check for plain
llcandoptif the explicitly versioned ones are not found. - If it finds plain
llcandoptcheck that the version isX.Y.
The above currently works, but causes other problems in this check:
checking whether bootstrap compiler is affected by bug 9439... You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/bin/opt-3.6: /tmp/ghc12163_0/ghc12163_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} ^ failed to compileThe problem here is that this checks the bootstrap compiler bug using the detected
LlcCmd(which now *must* bellc-3.6) which doesn't support he LLVM IR syntax above. I think is in-correct.The bootstrap compiler should already have the location of the
llcandoptit was compiled for in itssettingsfile (these have been present in that file since ghc 7.6 but they are not present in eg 7.4.2). Its the llc version in the settings file which should be checked for bug #9439 (closed), not the one detected by the configure script.- The configure script should check for
That's easy to fix. Revert this change I made in 1dfab7a8:
\--- a/configure.ac +++ b/configure.ac @@ -508,7 +508,7 @@ then echo "main = putStrLn \"%function\"" > conftestghc.hs # Check whether LLVM backend is default for this platform - "${WithGhc}" conftestghc.hs 2>&1 >/dev/null + "${WithGhc}" -pgmlc="${LlcCmd}" -pgmlo="${OptCmd}" conftestghc.hs 2>&1 >/dev/null res=`./conftestghc` if test "x$res" = "x%object" then @@ -525,7 +525,7 @@ then # -fllvm is not the default, but set a flag so the Makefile can check # -for it in the build flags later on - "${WithGhc}" -fforce-recomp -fllvm conftestghc.hs 2>&1 >/dev/null + "${WithGhc}" -fforce-recomp -pgmlc="${LlcCmd}" -pgmlo="${OptCmd}" -fllvm conftestghc.hs 2>&1 >/dev/null if test $? = 0 then res=`./conftestghc`Trac metadata
Trac field Value Differential revisions → D745 mentioned in commit 42448e37
changed milestone to %8.0.1
Hi, this seems to have regressed. Should I open a new ticket? I'd like for ghc to look for versioned llvm executables in the PATH and prefer those over the unversioned names (if they exist).
If #10074 is stalled this change seems sufficient to me. As it stands using multiple ghc versions with fllvm side by side is pretty inconvenient (or else I haven't figured out the trick).
$ echo $PATH /home/me/Code/NOT_MY_CODE/spack/bin:/usr/lib/llvm-6.0/bin:/home/me/.cargo/bin:/usr/local/go/bin:/home/me/.rbenv/shims:/home/me/.rbenv/bin:/home/me/.play-2.2.2:/home/me/.node/bin:/usr/local/node/bin:/home/me/.local/bin:/home/me/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin:/home/me/.gem/ruby/2.2.0/bin:/home/me/.go/bin $ which opt /usr/lib/llvm-6.0/bin/opt $ ghc --make -fforce-recomp -fllvm hello.hs -o hello_llvm [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello_llvm ... $ export PATH=/home/me/.cargo/bin:/usr/local/go/bin:/home/me/.rbenv/shims:/home/me/.rbenv/bin:/home/me/.play-2.2.2:/home/me/.node/bin:/usr/local/node/bin:/home/me/.local/bin:/home/me/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin:/home/me/.gem/ruby/2.2.0/bin:/home/me/.go/bin $ which opt opt not found $ which opt-6.0 1 ↵ /usr/bin/opt-6.0 $ ghc --make -fforce-recomp -fllvm hello.hs -o hello_llvm [1 of 1] Compiling Main ( hello.hs, hello.o ) <no location info>: error: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM 6.0 ghc: could not execute: optOh hm, it's not clear if this ticket was also (like #7661 (closed)) supposed to be about the ghc build system. I care about this as a user of ghc.
added Pnormal label
