[PATCH] D19986: Refactor the Verifier so it can diagnose IR validation errors and debug info metadata errors separately. (NFC)

[David Blaikie via llvm-commits]

seems like it'd be a bit of a performance hit to do this - compared to just
rolling the debug info version number & throwing out everything older. Is
it really worth it to take that performance hit for some uncertain amount
of debug info from old bitcode?

On Thu, May 5, 2016 at 11:11 AM, Adrian Prantl via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> aprantl created this revision.
> aprantl added reviewers: joker.eph, dexonsmith.
> aprantl added a subscriber: llvm-commits.
>
> This patch refactors the Verifier so it can diagnose IR validation errors
> and debug info metadata errors separately.
> The motivation behind this change is that broken (or outdated) debug info
> can be "recovered" from by stripping the debug info.
>
> The problem I'm trying to solve with this sequence of patches is that
> historically we've done a really bad job at verifying debug info. We want
> to be able to make the verifier stricter without having to worry about
> breaking bitcode compatibility with existing producers. For example, we
> don't necessarily want IR produced by an older version of clang to be
> rejected by an LTO link just because of malformed debug info, and rather
> provide an option to strip it. Note that merely outdated (but well-formed)
> debug info would continue to be auto-upgraded in this scenario.
>
> rdar://problem/25818489
>
> http://reviews.llvm.org/D19986
>
> Files:
>   lib/IR/Verifier.cpp
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160505/542d070c/attachment.html>