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

[Pete Cooper via llvm-commits]

> On Jan 11, 2016, at 1:55 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:
> 
> My intuition is that you're liable to change the crash (rather than
> reduce it) when touching arbitrary metadata like this.  Particularly
> with debug info, this stuff is fairly cross-referential, and a `null`
> reference can have some non-trivial meaning.
> 
> Well, the idea is that you run the verifier after doing the null replacement.
> As long as the Verifier understands the structure of debug info, the only cost
> you pay is a slightly longer reduction time.
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.

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.

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/4f66b01d/attachment.html>