llvm 3.5 JIT seems to generate bad code

[Steven Flintham]

The Raspbian version of LLVM 3.5 appears to have some fault in its JIT.

I have taken the toy.cpp code at the bottom of this page:
http://llvm.org/releases/3.5.0/docs/tutorial/LangImpl4.html

and compiled it:
g++ -g toy.cpp `llvm-config-3.5 --cxxflags --ldflags --system-libs --libs core jit native` -O3 -o toy -rdynamic

It runs, but it generates bad output:

$ ./toy
ready> def test(x) 1+2+x;
ready> Read function definition:
define double @test(double %x) {
entry:
  %addtmp = fadd double 3.000000e+00, %x
  ret double %addtmp
}

ready> test(4);
ready> Evaluated to 11.000002 <-- 1+2+4 is not 11
ready> test(5);
ready> Evaluated to 5.000001 <-- 1+2+5 is not 5

My desktop PC running Ubuntu 14.04 (x64) gives correct results with this code:

$ g++ -g toy.cpp `llvm-config-3.5 --cxxflags --ldflags --system-libs --libs core jit native` -O3 -o toy -rdynamic
$ ./toy
ready> def test(x) 1+2+x;
ready> Read function definition:
define double @test(double %x) {
entry:
  %addtmp = fadd double 3.000000e+00, %x
  ret double %addtmp
}

ready> test(4);
ready> Evaluated to 7.000000
ready> test(5);
ready> Evaluated to 8.000000

The following commands hopefully show the necessary information about my Raspbian installation, please let me know if you need any more details.

pi@raspberrypi:~/llvm-simple $ uname -a
Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
pi@raspberrypi:~/llvm-simple $ dpkg -s libc6 | grep ^Version
Version: 2.19-18+deb8u1
pi@raspberrypi:~/llvm-simple $ dpkg -l | grep -i llvm
ii libllvm3.5:armhf 1:3.5-10+rpi1 armhf Modular compiler and toolchain technologies, runtime library
ii llvm-3.5 1:3.5-10+rpi1 armhf Modular compiler and toolchain technologies
ii llvm-3.5-dev 1:3.5-10+rpi1 armhf Modular compiler and toolchain technologies, libraries and headers
ii llvm-3.5-runtime 1:3.5-10+rpi1 armhf Modular compiler and toolchain technologies, IR interpreter

[Matthijs Kooijman (matthijskooijman)]

I tried to reproduce this problem (since I was running into a LLVM miscompile myself, unrelated to JIT), but it seems LLVM 3.5 is no longer included in Raspbian Buster. I tried LLVM 3.7 (using the example code and updated commandline from http://releases.llvm.org/3.7.0/docs/tutorial/LangImpl4.html, and it seems the problem still exists.

To test this, I had to install the llvm-3.7-dev and libedit-dev packages.

I did run into a compiler error:

In file included from /usr/lib/llvm-3.7/include/llvm/ExecutionEngine/ExecutionEngine.h:24,
                 from toy.cpp:2:
/usr/lib/llvm-3.7/include/llvm/IR/ValueMap.h: In member function ‘bool llvm::ValueMap<KeyT, ValueT, Config>::hasMD() const’:
/usr/lib/llvm-3.7/include/llvm/IR/ValueMap.h:102:31: error: cannot convert ‘const std::unique_ptr<llvm::DenseMap<const llvm::Metadata*, llvm::TrackingMDRef> >’ to ‘bool’ in return
   bool hasMD() const { return MDMap; }

which I can't really explain, since std::unique_ptr should have an operator bool() that can be used here (llvm-config already returns the -std=c++11 that is needed for that). I worked around it by replacing the referenced line (in a system header file :-S) by:

  bool hasMD() const { return MDMap.get()!=nullptr; }

With that, it compiles and runs:

$ g++ -g toy.cpp `llvm-config-3.7 --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy
$ ./toy

ready> def test(x) 1+2+x;
ready> Read function definition:
define double @test(double %x) {
entry:
  %addtmp = fadd double 3.000000e+00, %x
  ret double %addtmp
}

ready> test(4);
ready> Evaluated to 0.000000
ready> test(5);
ready> Evaluated to 0.000000
ready>

The behaviour is different from the original poster's, but still wrong.

I also tried replacing the libllvm3.7 using the armhf version from Debian rather than Raspbian (since that, but for libllvm7, fixed the other issue I was seeing), but that did not help here (it also seems libllvm3.7 has no Raspbian-specific source changes, unlike libllvm7).

I tried with llvm-9 as well, but that seems to be a development version and the JIT example would not compile there either (and I did not care to fix that either).

Note that I'm not particularly interested in further chasing this issue, just wondered if it would be related to my own issue (which it seems not).