Bug in LoopSimplfy pass

[asl]

Bugzilla Link	1246
Resolution	FIXED
Resolved on	Nov 07, 2018 00:17
Version	trunk
OS	Linux
Depends On	#1617
Attachments	Failed bytecode
CC	@lattner

Extended Description

Consider the attached bytecode. Be careful with re-assembling - you can hit #1617 .

Everything is ok with "llc -fast" or with disabled LoopStrengthReduce pass (or
cbe), but segfault with enabled.

Segfault occurs in bb43 BB. The variable %i1.0_cc becames uninitialized.
Initialization occurs in the meshBB BB, but it seems, that LSR incorrectly moves
it somewhere.

Target triple is, unfortunately, set to mingw32, but bytecode should run ok any
ia32 platform, it doesn't contain any target-specific code. Unfortunately, until
#1617 is fixed, I cannot change it :(

Please also note, that "opt -std-compile-opts" is buggy on this bytecode, but
it's subject for future investigation (maybe due to #1617 ).

[asl]

Well, now it's safe to switch target triple to "linux" or something else.
Another addition: ./opt -licm produces incorrect results on this bytecode
probably due to same reason, as LSR.

[lattner]

Evan, can you take a quick look to see if this is something obvious? thx,

-Chris

[asl]

Well, after recent changes inside LSR (courtesy of Dale) the testcase is not
crashing anymore, but just reporting incorrect results (was it expected? :) ).

CBE is working fine, -fast (disable LSR) too. In order to get running binary you
have just change target from "mingw32" to anything you like (I've tested with
"linux" and it was ok).

Consider input:

rows: N = 2
cols: M = 2

Matrix[1, 1] = 1
Matrix[1, 2] = 2
Matrix[2, 1] = 3
Matrix[2, 2] = 4

The correct output is:

out[0] = 2
out[1] = 2

LICM is broken too, probably due to some common code/algorithm with LSR.

[lattner]

Dale, can you please investigate this?

-Chris

[llvmbot]

Duplicated on darwin, sort of: acts as he says it is supposed to with -fast, acts differently without.
Could you put the source here? It's kind of hard to figure out what's going on without it.

[asl]

Dale, this is result of some LLVM-to-LLVM trasformation. Our code usually
triggers many "corner" and "bad" cases inside LLVM. :(

I've just monitored -debug output and watch, what LSR is "moving"... LICM is
also broken, so, you can try 'opt -licm' and compare result.

[llvmbot]

I've stepped through LSR and don't think that's where the problem is, it is not doing anything invalid. It's
tickling a bug later somehow. Still looking.

[asl]

I've tried just comment LSR and it worked! Will try again and report results.

[asl]

It's definitely LSR issue. Or something closely related.

I've just commented LSR call in the Codegen/LLVMTargetMachine.cpp
Resulted binary (without -fast) runs ok.

I've made another test:

1. Run opt -loop-reduce test.bc -o test-o.bc
2. lli -force-interpreter test-o.bc. It crashed
3. lli test-o.bc. It doesn't crashed but showed garbage(!)
4. llc -march=c test-o.bc. It produce incorrect results.

In cases 2-4 valgrind reported uninitialized read. So, I think the problem is LSR.

[asl]

CBE output
Maybe this will help somehow. I'm attaching CBE output after opt -loop-reduce.

valgrind teels, that:

==21038== Use of uninitialised value of size 4
==21038== at 0x804A3BB: ProcessingArray (test3.lsr.cbe.c:1312)
==21038== by 0x804BA01: main (test3.lsr.cbe.c:2117)
==21038==

[asl]

Well. "Bad" variable is %i1.093 used in gep the early beginning of BB43.
Originally %i1.0_cc variable was used there.

[asl]

Maybe, it will be more convenient to run "opt -instcombine -simplifycfg" on .bc
first. Everything is still the same there (even "bad" register names).

[llvmbot]

Yes, I see the substitution of i1.093 for i1.0_cc. Does look wrong.

[llvmbot]

Yes, I see the substitution of i1.093 for i1.0_cc. Does look wrong. Thanks!

[llvmbot]

However, this has already happened when we get to LSR...