[PATCH] D16083: [bugpoint] Teach bugpoint to reduce MDNodes

[Keno Fischer via llvm-commits]

> Running the verifier was my solution too.
>
> I wrote my patch over a year ago, well before Duncan had improved the
> verifier to the point where it is now.
>
> I found that reducing the debug info metadata for all of llc in a single
> bc was enough to crash the backend because of mismatches between the
> asserts in DwarfDebug.cpp and the verifier.  I took a quick look and the
> verifier seems much more comprehensive now so I’d expect any fallout from
> this to be easy enough to improve the verifier.
>

I ran some fairly big bc files through this and it worked fine, but I would
be happy to run some more test cases. How were you running it on the llc
.bc, i.e. what crash were you looking for?


> If you’re curious, my solution did involve knowing more about the format
> of the debug info its.  I reduced each of the fields of the compile unit
> (types, enums, imports, etc) all the way to empty arrays if possible.  Then
> once the CU entries were 0, I could also remove references to the debug
> info from instructions, and try to get to a small number of references from
> instructions or the remaining entries in the compile unit.  It seemed to
> work pretty reasonably.
>
> I believe Adrian’s approach was to look for multiple compile units and
> remove whole compile units first.  That is a huge win on LTO where you may
> be able to remove all but the bad compile unit.
>

Do note that I already wrote some code a while back to drop the arguments
of named metadata, which does a pretty good job of getting rid of whole
compile units which are not needed to reproduce the crash. That pass runs
before getting to to this.


> My code is well out of date, so i wouldn’t suggest we revisit it, but its
> interesting to see the alternative approach.
>
> As for the patch itself, i’ll take a look in phab.  Don’t want to confuse
> things with email comments on the code itself.
>
> Thanks,
> Pete
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160111/27d17347/attachment.html>