search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

tablegen doesn't work when compiled with LTO #4814

Closed Quuxplusone closed 14 years ago

Quuxplusone commented 15 years ago
Bugzilla Link PR4313
Status RESOLVED FIXED
Importance P normal
Reported by Török Edwin (edwin+bugs@etorok.eu)
Reported on 2009-06-03 11:31:42 -0700
Last modified on 2009-11-08 22:30:21 -0800
Version unspecified
Hardware PC Linux
CC anton@korobeynikov.info, baldrick@free.fr, devang.patel@gmail.com, efriedma@quicinc.com, llvm-bugs@lists.llvm.org, nicholas@mxc.ca, nlewycky@google.com
Fixed by commit(s)
Attachments orig.bc (49368 bytes, application/octet-stream)
func.bc (49332 bytes, application/octet-stream)
thediff.bz2 (79415 bytes, application/octet-stream)
Blocks
Blocked by PR4322
See also 
If I compile LLVM with LTO on Linux, by using instructions from here
http://llvm.org/docs/GoldPlugin.html#lto_autotools, and additionally doing
make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O4, then tablegen crashes with heap
corruption.

OPTIMIZE_OPTION=-O3 works fine, valgrind is clean; with OPTIMIZE_OPTION=-O4
valgrind reports use-after-free.

I can reproduce this with llvm-ld too, -disable-opt works fine, defaults create
bugged tblgen.

Here's how I've run bugpoint:
bugpoint -run-llc -safe-run-llc -internalize -ipsccp -globalopt -constmerge -
deadargelim -instcombine -basiccg -inline -prune-eh -globalopt -globaldce -
basiccg -argpromotion -instcombine -jump-threading -domtree -domfrontier -
scalarrepl -basiccg -functionattrs -globalsmodref-aa -domtree -loops -
loopsimplify -domfrontier -licm -memdep -gvn -memdep -memcpyopt -dse -
instcombine -jump-threading -domtree -domfrontier -mem2reg -simplifycfg -
globaldce -instcombine -simplifycfg -adce -globaldce -preverify -domtree -
verify /home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/AsmWriterEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/CallingConvEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/ClangDiagnosticsEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/CodeEmitterGen.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/CodeGenDAGPatterns.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/CodeGenInstruction.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/CodeGenTarget.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/DAGISelEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/FastISelEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/InstrEnumEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/InstrInfoEmitter.o
/home/edwin/llvm-svn/llvm-lto/utils/TableGen/Release/IntrinsicEmitter.o
/home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/LLVMCConfigurationEmitter.o /home/edwin/llvm-
svn/llvm-lto/utils/TableGen/Release/Record.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/RegisterInfoEmitter.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/SubtargetEmitter.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TGLexer.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TGParser.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TGSourceMgr.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TGValueTypes.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TableGen.o /home/edwin/llvm-svn/llvm-
lto/utils/TableGen/Release/TableGenBackend.o -Xlinker=-lLLVMSupport -Xlinker=-
lLLVMSystem -Xlinker=/usr/lib/libstdc++.so.6 -Xlinker=-lpthread -Xlinker=-ldl --
args -I /home/edwin/llvm-svn/llvm/lib/VMCore -I /home/edwin/llvm-
svn/llvm/include -I /home/edwin/llvm-svn/llvm/include -I /home/edwin/llvm-
svn/llvm/lib/Target /home/edwin/llvm-svn/llvm/include/llvm/Intrinsics.td -o
/home/edwin/llvm-svn/llvm-lto/lib/VMCore/Release/Intrinsics.gen.tmp -gen-
intrinsic

I haven't got a reduced .bc file yet, will attach when I have one.
Quuxplusone commented 15 years ago 
This is due to -instcombine being run on the LTO-ed program:
*** Found miscompiling pass: -instcombine
Emitted bitcode to 'bugpoint-passinput.bc'

*** You can reproduce the problem with: opt bugpoint-passinput.bc -instcombine

*** The following function is being miscompiled:
_ZN4llvm16IntrinsicEmitter28EmitIntrinsicToGCCBuiltinMapERKSt6vectorINS_16CodeGenIntrinsicESaIS2_EERSo

Unfortunately bugpoint started to debug a LLC crash again
Quuxplusone commented 15 years ago 
%68 = invoke %"struct.std::pair<long unsigned int,long unsigned int>"
@_ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE16_M_insert_uniqueERKS2_(...)
                        to label %invcont14 unwind label %lpad143
 invcont14:             ; preds = %invcont13
        %mrv_gr2.i = extractvalue %"struct.std::pair<long unsigned int,long
unsigned int>" %68, 1

The %68 is turned into undef by some optimization, and then instcombine makes
mrv_gr2.i undef too, later a branch depends on this which now becomes undef.

I haven't figured out why %68 is used in the landing pad though, or why the
verifier even accepts this code.
Quuxplusone commented 15 years ago 
(In reply to comment #2)
>     %68 = invoke %"struct.std::pair<long unsigned int,long unsigned int>"
>
@_ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE16_M_insert_uniqueERKS2_(...)
>                         to label %invcont14 unwind label %lpad143
>  invcont14:             ; preds = %invcont13
>         %mrv_gr2.i = extractvalue %"struct.std::pair<long unsigned int,long
> unsigned int>" %68, 1
>
>
> The %68 is turned into undef by some optimization, and then instcombine makes
> mrv_gr2.i undef too, later a branch depends on this which now becomes undef.
>
> I haven't figured out why %68 is used in the landing pad though, or why the
> verifier even accepts this code.
>

Oops, invcont14 is not the landing pad. Then the above code should be valid,
and optimizers shouldn't change %68 to undef!
Quuxplusone commented 15 years ago

Attached orig.bc (49368 bytes, application/octet-stream): original function as compiled by -O4

Quuxplusone commented 15 years ago

Attached func.bc (49332 bytes, application/octet-stream): func.bc

Quuxplusone commented 15 years ago 
(In reply to comment #1)
> This is due to -instcombine being run on the LTO-ed program:
> *** Found miscompiling pass: -instcombine
> Emitted bitcode to 'bugpoint-passinput.bc'
>
> *** You can reproduce the problem with: opt bugpoint-passinput.bc -instcombine

Can you attach that file?
Quuxplusone commented 15 years ago 
(In reply to comment #6)
> (In reply to comment #1)
> > This is due to -instcombine being run on the LTO-ed program:
> > *** Found miscompiling pass: -instcombine
> > Emitted bitcode to 'bugpoint-passinput.bc'
> >
> > *** You can reproduce the problem with: opt bugpoint-passinput.bc -
instcombine
>
> Can you attach that file?
>

No, bugzilla rejects it (3.0M).
I uploaded it here:
http://edwintorok.googlepages.com/bugpoint-passinput.bc

%68 = invoke fastcc i64
@_ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE16_M_insert_uniqueERKS2_(%"...
to label %invcont14 unwind label %lpad143       ; <i64> [#uses=0]

invcont14:      ; preds = %invcont13
    %mrv_gr2.i = extractvalue %"struct.std::pair<long unsigned int,long unsigned
int>" undef, 1

It looks like it already contains undef.
Quuxplusone commented 15 years ago

Okay... it looks like something is going wrong in one of the inter-procedural passes, perhaps IPSCCP. Can you try and check which pass is doing this bad transformation?

Quuxplusone commented 15 years ago 
(In reply to comment #8)
> Okay... it looks like something is going wrong in one of the inter-procedural
> passes, perhaps IPSCCP.  Can you try and check which pass is doing this bad
> transformation?
>

Tablegen no longer crashes when LTOed by LLVM2.6 prerelease1, however there is
still something wrong:

edwin@debian:~/llvm2.6/objlto/lib/VMCore$
/home/edwin/llvm2.6/objlto/Release/bin/tblgen -I  /home/edwin/llvm2.6/llvm-
2.6/lib/VMCore -I  /home/edwin/llvm2.6/llvm-2.6/include -I
/home/edwin/llvm2.6/llvm-2.6/include -I  /home/edwin/llvm2.6/llvm-
2.6/lib/Target  /home/edwin/llvm2.6/llvm-2.6/include/llvm/Intrinsics.td -o
/home/edwin/llvm2.6/objlto/lib/VMCore/Release/Intrinsics.gen.tmp -gen-intrinsic
/home/edwin/llvm2.6/objlto/Release/bin/tblgen: Intrinsic 'int_alpha_umulh':
duplicate GCC builtin name!
Quuxplusone commented 15 years ago

Attached thediff.bz2 (79415 bytes, application/octet-stream): -ipsccp diff

Quuxplusone commented 15 years ago 
(In reply to comment #10)
> Created an attachment (id=3409) [details]
> -ipsccp diff
>
> It is -ipsccp that introduces the undefined value!
>            to label %invcont93.i unwind label %lpad194.i
>
>  invcont93.i:
> -  %mrv_gr3.i.i = extractvalue %"struct.std::pair<long unsigned int,long
> unsigned int>" %949, 1
> +  %mrv_gr3.i.i = extractvalue %"struct.std::pair<long unsigned int,long
> unsigned int>" undef, 1
>
>
> Without -ipsccp tblgen is valgrind clean, so there are no undefined values
> being used.
>
> Attached is the .ll diff of bugpoint-passinput.bc and -ipsccp run on that.
>

I uploaded bugpoint-passinput.bc here:
http://www.fileden.com/files/2009/9/1/2561232/bugpoint-passinput.bc

Here's how I've run bugpoint:
bugpoint -output=out -mlimit=0 -run-llc -safe-run-llc -internalize -ipsccp -
globalopt -constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -
globalopt -globaldce -basiccg -argpromotion -instcombine -jump-threading -
domtree -domfrontier -scalarrepl -basiccg -functionattrs -globalsmodref-aa -
domtree -loops -loopsimplify -domfrontier -licm -memdep -gvn -memdep -memcpyopt
-dse -instcombine -jump-threading -domtree -domfrontier -mem2reg -simplifycfg -
globaldce -instcombine -simplifycfg -adce -globaldce -preverify -domtree -
verify /home/edwin/llvm2.6/objlto/utils/TableGen/Release/AsmMatcherEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/AsmWriterEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/CallingConvEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/ClangDiagnosticsEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/CodeEmitterGen.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/CodeGenDAGPatterns.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/CodeGenInstruction.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/CodeGenTarget.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/DAGISelEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/FastISelEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/InstrEnumEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/InstrInfoEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/IntrinsicEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/LLVMCConfigurationEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/Record.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/RegisterInfoEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/SubtargetEmitter.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/TGLexer.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/TGParser.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/TGValueTypes.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/TableGen.o
/home/edwin/llvm2.6/objlto/utils/TableGen/Release/TableGenBackend.o -Xlinker=-
L/usr/local/lib -Xlinker=-lLLVMSupport -Xlinker=-lLLVMSystem -
Xlinker=/usr/lib/libstdc++.so.6 -Xlinker=-lpthread -Xlinker=-lffi -Xlinker=-ldl
-Xlinker=-lm --args -I /home/edwin/llvm2.6/llvm-2.6/lib/VMCore -I
/home/edwin/llvm2.6/llvm-2.6/include -I /home/edwin/llvm2.6/llvm-2.6/include -I
/home/edwin/llvm2.6/llvm-2.6/lib/Target /home/edwin/llvm2.6/llvm-
2.6/include/llvm/Intrinsics.td -o
/home/edwin/llvm2.6/objlto/lib/VMCore/Release/Intrinsics.gen.tmp -gen-intrinsic
Quuxplusone commented 15 years ago

Is someone actively working on this? If you get the fix soon (by end of the week), its possible to have it merged in (if code owner approves).

I am removing this as a blocker for 2.6 since its not addressing one of our defined regressions.

Quuxplusone commented 14 years ago

Fixed in r84637, it was a bug in -ipsccp, it was not setting the lattice value for the invoke instruction when it had multiple return values.

Quuxplusone commented 14 years ago

Reopening this bug. There is no testcase for it. The testcase passes when the patch isn't applied.

Quuxplusone commented 14 years ago

I added a testcase in r84676

Quuxplusone commented 14 years ago

refixed on mainline