llvm dev - Oct 2017 - IR Pass Ordering Sensitivity

Hi,

I'm trying to autotune a good sequence of IR optimization passes and I seem
to run into segfaults in opt (in LLVM5) with certain pass orderings.

Is this expected behavior? If so, what would be the recommended way of
determining pass dependencies so that I can encode them into the tuner?


The test program can be found here: 
https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

Here's what happens:
kavon at cronus:~/m/autotune|master⚡*?
➤ /Users/kavon/msr/llvm5/bin/opt  -inline -mem2reg -inferattrs -ipconstprop -gvn
-simplifycfg -bdce -sink -dse -adce -instcombine -early-cse-memssa
-early-cse-memssa -dse -adce -simplifycfg -sink -ipconstprop -gvn -bdce
-instcombine -jump-threading -inline -sroa ./src/apps/raytracer.bc -o
./out/raytracer_opt1043.bc
0  opt                      0x000000010ebd4498
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  opt                      0x000000010ebd4a46 SignalHandler(int) + 342
2  libsystem_platform.dylib 0x00007fff8ce5352a _sigtramp + 26
3  opt                      0x000000010eb8ef4f
llvm::StringMapImpl::FindKey(llvm::StringRef) const + 303
4  opt                      0x000000010e770235
llvm::PMDataManager::add(llvm::Pass*, bool) + 917
5  opt                      0x000000010e76d6ef
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 2367
6  opt                      0x000000010d755c9e main + 8846
7  libdyld.dylib            0x00007fff8c0c85ad start + 1
8  libdyld.dylib            0x000000000000001c start + 1945336432
Stack dump:
0.	Program arguments: /Users/kavon/msr/llvm5/bin/opt -inline -mem2reg
-inferattrs -ipconstprop -gvn -simplifycfg -bdce -sink -dse -adce -instcombine
-early-cse-memssa -early-cse-memssa -dse -adce -simplifycfg -sink -ipconstprop
-gvn -bdce -instcombine -jump-threading -inline -sroa ./src/apps/raytracer.bc -o
./out/raytracer_opt1043.bc
fish: “/Users/kavon/msr/llvm5/bin/opt…” terminated by signal SIGSEGV (Address
boundary error)

Thanks,
Kavon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171014/53454f7e/attachment.html>

These are definitely LLVM bugs. It would be best to report reduced test 
cases against top of tree.

We should have some automated infrastructure for finding these too...

John


On 10/13/17 11:06 PM, Kavon Farvardin via llvm-dev
wrote:
> Hi,
> 
> I'm trying to autotune a good sequence of IR optimization passes and I 
> seem to run into segfaults in opt (in LLVM5) with certain pass orderings.
> 
> Is this expected behavior? If so, what would be the recommended way of 
> determining pass dependencies so that I can encode them into the tuner?
> 
> 
> The test program can be found here: 
> https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95
> 
> Here's what happens:
> 
> kavon at cronus:~/m/autotune|master⚡*?
> ➤ /Users/kavon/msr/llvm5/bin/opt  -inline -mem2reg -inferattrs -ipconstprop
-gvn -simplifycfg -bdce -sink -dse -adce -instcombine -early-cse-memssa
-early-cse-memssa -dse -adce -simplifycfg -sink -ipconstprop -gvn -bdce
-instcombine -jump-threading -inline -sroa ./src/apps/raytracer.bc -o
./out/raytracer_opt1043.bc
> 0  opt                      0x000000010ebd4498
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
> 1  opt                      0x000000010ebd4a46 SignalHandler(int) + 342
> 2  libsystem_platform.dylib 0x00007fff8ce5352a _sigtramp + 26
> 3  opt                      0x000000010eb8ef4f
llvm::StringMapImpl::FindKey(llvm::StringRef) const + 303
> 4  opt                      0x000000010e770235
llvm::PMDataManager::add(llvm::Pass*, bool) + 917
> 5  opt                      0x000000010e76d6ef
llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 2367
> 6  opt                      0x000000010d755c9e main + 8846
> 7  libdyld.dylib            0x00007fff8c0c85ad start + 1
> 8  libdyld.dylib            0x000000000000001c start + 1945336432
> Stack dump:
> 0.	Program arguments: /Users/kavon/msr/llvm5/bin/opt -inline -mem2reg
-inferattrs -ipconstprop -gvn -simplifycfg -bdce -sink -dse -adce -instcombine
-early-cse-memssa -early-cse-memssa -dse -adce -simplifycfg -sink -ipconstprop
-gvn -bdce -instcombine -jump-threading -inline -sroa ./src/apps/raytracer.bc -o
./out/raytracer_opt1043.bc
> fish: “/Users/kavon/msr/llvm5/bin/opt…” terminated by signal SIGSEGV
(Address boundary error)
> 
> 
> Thanks,
> Kavon
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On Sat, Oct 14, 2017 at 11:05 AM, John Regehr via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> These are definitely LLVM bugs. It would be best to report reduced test
> cases against top of tree.
>
> We should have some automated infrastructure for finding these too...
>
> John
>
Zhendong & friends generally do that (and reported many bugs :) I
tried that myself, but never got to automate the whole procedure.
While the problem is combinatorial in nature, evidence shows that you
don't need to enumerate all the possible combination of passes to
break LLVM. I think an `opt` option would be a good start. You can
then take the testsuite and run with that, or generate random IR with
llvm-stress and pipe that to opt. The swift folks have a slightly more
sophisticated infrastructure for doing this (you can dump the SIL
pipeline in a YAML file, and then IIRC, feed that back to `sil-opt`),
but something simpler will do, IMHO. Happy to discuss this further if
folks are in California next week :)

Thanks,

--
Davide