bugpoint doesn't binary search with run-custom

[Quuxplusone]

Bugzilla Link	PR4937
Status	NEW
Importance	P normal
Reported by	Török Edwin (edwin+bugs@etorok.eu)
Reported on	2009-09-09 13:43:37 -0700
Last modified on	2019-09-06 06:30:48 -0700
Version	trunk
Hardware	PC Linux
CC	daniel@zuster.org, llvm-bugs@lists.llvm.org, nicholas@mxc.ca
Fixed by commit(s)
Attachments	0001-Add-TrackingVH-class-and-switch-DIDescriptor-to-use-.patch (4526 bytes, application/octet-stream)
Blocks
Blocked by
See also

Running bugpoint on the bugpoint-passinput.bc from
http://www.fileden.com/files/2009/9/1/2561232/bugpoint-passinput.bc which is
3.5M results a bugpoint-tooptimize.bc that is 3.4M.

I think that if bugpoint did a binary search on the functions it could narrow
it down more.

My custom.sh looks like this:
#!/bin/sh
llvm-dis $1 -o -|grep extractvalue|grep undef >/dev/null
test $? -eq 0 && exit 1
echo "OK"
exit 0

Basically -ipsccp transforms extractvalue %949, 1 into extractvalue undef, 1,
and I want to reduce a testcase for that. Thus if there is an
extractvalue..undef in the output, then its bugged.

$ bugpoint -disable-loop-extraction -mlimit=0 -ipsccp --append-exit-code -run-
custom -safe-run-custom -exec-command=./custom.sh bugpoint-passinput.bc
...
override triple is
Read input file      : 'bugpoint-passinput.bc'
*** All input ok
Running selected passes on program to test for crash: override triple is
Success!
Initializing execution environment: Found command in: ./custom.sh
Running the code generator to test for a crash:
Generating reference output from raw program:
Reference output is: bugpoint.reference.out-sxXqxN

*** Checking the code generator...

*** Output matches: Debugging miscompilation!
Checking to see if '' compiles correctly: override triple is
 yup.
Checking to see if '-ipsccp' compiles correctly: override triple is
 nope.

*** Found miscompiling pass: -ipsccp
Emitted bitcode to 'bugpoint-passinput.bc'

*** You can reproduce the problem with: opt bugpoint-passinput.bc -ipsccp
Checking to see if the program is misoptimized when these functions are run
through the pass: _ZN4llvm17AsmMatcherEmitter3runERNS_11raw_ostreamE
_GLOBAL__I__ZN4llvm17AsmMatcherEmitter3runERNS_11raw_ostreamE
_ZNK12_GLOBAL__N_19ClassInfo10isSubsetOfERKS0_
_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISt3setIPN4llvm6RecordESt4lessIS3_ESaIS3_EES7_St9_IdentityIS7_ES4_IS7_ESaIS7_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordESt4pairIKS2_St3setIS2_St4lessIS2_ESaIS2_EEESt10_Select1stISA_ES7_SaISA_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISt3setIPN4llvm6RecordESt4lessIS3_ESaIS3_EESt4pairIKS7_PN12_GLOBAL__N_19ClassInfoEESt10_Select1stISD_ES4_IS7_ESaISD_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordESt4pairIKS2_PN12_GLOBAL__N_19ClassInfoEESt10_Select1stIS8_ESt4lessIS2_ESaIS8_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISsSt4pairIKSsPN12_GLOBAL__N_19ClassInfoEESt10_Select1stIS5_ESt4lessISsESaIS5_EE7_S_leftEPSt18_Rb_tree_node_base...
<1642 total>
  Optimizing functions being tested: override triple is
done.
  Checking to see if the merged program executes correctly:  yup.

*** The following functions are being miscompiled:
_ZN4llvm17AsmMatcherEmitter3runERNS_11raw_ostreamE
_GLOBAL__I__ZN4llvm17AsmMatcherEmitter3runERNS_11raw_ostreamE
_ZNK12_GLOBAL__N_19ClassInfo10isSubsetOfERKS0_
_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISt3setIPN4llvm6RecordESt4lessIS3_ESaIS3_EES7_St9_IdentityIS7_ES4_IS7_ESaIS7_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordESt4pairIKS2_St3setIS2_St4lessIS2_ESaIS2_EEESt10_Select1stISA_ES7_SaISA_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISt3setIPN4llvm6RecordESt4lessIS3_ESaIS3_EESt4pairIKS7_PN12_GLOBAL__N_19ClassInfoEESt10_Select1stISD_ES4_IS7_ESaISD_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeIPN4llvm6RecordESt4pairIKS2_PN12_GLOBAL__N_19ClassInfoEESt10_Select1stIS8_ESt4lessIS2_ESaIS8_EE7_S_leftEPSt18_Rb_tree_node_base
_ZNSt8_Rb_treeISsSt4pairIKSsPN12_GLOBAL__N_19ClassInfoEESt10_Select1stIS5_ESt4lessISsESaIS5_EE7_S_leftEPSt18_Rb_tree_node_base...
<1642 total>
Checking to see if the program is misoptimized when all blocks are extracted.
override triple is
  Optimizing functions being tested: override triple is
done.
  Checking to see if the merged program executes correctly:  yup.
Checking to see if the program is misoptimized when all but these 63372 blocks
are extracted: entry bb2.i invcont8 bb12 bb.i.i363 bb.i.i.i364 bb1.i.i.i365
_ZN9__gnu_cxxL27__exchange_and_add_dispatchEPii.exit.i.i366 bb2.i.i367 bb17 ...
override triple is
Optimizing functions being tested: override triple is
done.
  Checking to see if the merged program executes correctly:  yup.
Outputting reduced bitcode files which expose the problem:
  Non-optimized portion: Emitted bitcode to 'bugpoint-tonotoptimize.bc'
  Portion that is input to optimizer: Emitted bitcode to 'bugpoint-tooptimize.bc'

*** You can reproduce the problem with: opt bugpoint-tooptimize.bc -ipsccp

[Quuxplusone]

Ok ignore the patch here, stupid bugzilla.

[Quuxplusone]

Attached 0001-Add-TrackingVH-class-and-switch-DIDescriptor-to-use-.patch (4526 bytes, application/octet-stream): Patch to adding TrackingVH.