I am getting wrong code from one of the passes, namely instcombine. I
see it in my JIT application when calling the pass directly through a
pass manager.
It was not possible for me to reproduce this behaviour with 'opt'
however I could isolate the IR and write a minimal 'opt' myself and
reproduce it.
As you can see the input IR (f.ll) operates most of the time with
floating point numbers and strangly the instcombine pass replaces some
float* with i32*. This is wrong and completely messes up the code and
gives strange restults and segfaults.
I attach the input IR, program and output:
f.ll (input IR)
main.cc (reads f.ll and applies the passes and prints out the
resulting IR)
f_main.ll (output of main)
You can see in f_main.ll strange bitcasts and loads to i32*.
I am getting wrong code from one of the passes, namely instcombine. I
see it in my JIT application when calling the pass directly through a
pass manager.
It was not possible for me to reproduce this behaviour with 'opt'
however I could isolate the IR and write a minimal 'opt' myself and
reproduce it.
As you can see the input IR (f.ll) operates most of the time with
floating point numbers and strangly the instcombine pass replaces some
float* with i32*. This is wrong and completely messes up the code and
gives strange restults and segfaults.
I attach the input IR, program and output:
f.ll (input IR)
main.cc (reads f.ll and applies the passes and prints out the
resulting IR)
f_main.ll (output of main)
You can see in f_main.ll strange bitcasts and loads to i32*.
First your IR does not have a triple/datalayout.
Second you should add -targetlibinfo -tti at the beginning of the opt arguments list.
And finally, it’ll help in general to get the IR right before instcombine so that you can reproduce with opt -instcombine alone.
For example by modifying your program to comment out the run of InstCombine.