This is an archive of the discontinued LLVM Phabricator instance.

Don't verify cross-imported bitcode in FunctionImporter
ClosedPublic

Authored by aprantl on May 19 2017, 3:17 PM.

Details

Summary

After landing https://reviews.llvm.org/D33151 I promptly broke the green dragon ThinLTO buildbot[1]. It turns out that the SrcModule in FunctionImporter is in a really inconsistent intermediate state at the point where I ran the Verifier. After poking around a bit I came to the conclusion that it probably isn't even desirable to run the full-module verifier on each cross-imported module: Over the course of building the entire project the same module will be verified over and over again, which is a waste of resources. When we want to lazy-load metadata running a whole-module Verifier is also problematic.

This patch partially reverts D33151 and instead only runs the verifier once on the module after the cross-imports are done.

The downside is that this won't be able to catch verifier issues that will cause crashes during the import itself, but I think that is an acceptable trade-off.

[1] http://green.lab.llvm.org/green/job/clang-stage2-configure-Rthinlto_build/1850/consoleFull

Diff Detail

Repository
rL LLVM

Event Timeline

aprantl created this revision.May 19 2017, 3:17 PM
mehdi_amini edited edge metadata.May 19 2017, 3:30 PM

It turns out that the SrcModule in FunctionImporter is in a really inconsistent intermediate state at the point where I ran the Verifier.

Oh right I forgot about this: lazy-loaded modules, even after materializing metadata, aren't passing the verified. This is super annoying.

After poking around a bit I came to the conclusion that it probably isn't even desirable to run the full-module verifier on each cross-imported module: Over the course of building the entire project the same module will be verified over and over again, which is a waste of resources. When we want to lazy-load metadata running a whole-module Verifier is also problematic.

There is something I'm missing: I thought the important part of the verifier was to be able to drop stalled debug information which is important for backward compatibility? This is the only reason I suggested doing it at this point of the process (before importing)...

It turns out that the SrcModule in FunctionImporter is in a really inconsistent intermediate state at the point where I ran the Verifier.

Oh right I forgot about this: lazy-loaded modules, even after materializing metadata, aren't passing the verified. This is super annoying.

After poking around a bit I came to the conclusion that it probably isn't even desirable to run the full-module verifier on each cross-imported module: Over the course of building the entire project the same module will be verified over and over again, which is a waste of resources. When we want to lazy-load metadata running a whole-module Verifier is also problematic.

There is something I'm missing: I thought the important part of the verifier was to be able to drop stalled debug information which is important for backward compatibility? This is the only reason I suggested doing it at this point of the process (before importing)...

That is correct*. This why I mentioned that doing it like in this patch will not catch any metadata so egregiously wrong that it would crash the FunctionImporter. If the debug info is structurally sound and can be handled by the FunctionImporter then doing the full verification after importing will still allow us to strip malformed imported debug info.

*) note that it isn't really about backwards-compatibility (we have auto-upgrades for that), but about metadata generated by non-clang frontends. If we have to support every metadata every produced by any frontend and at one point accepted by the verifier, we could effectively never improve the verifier by making it stricter — and historically the verifier was very lax.

mehdi_amini accepted this revision.May 19 2017, 4:39 PM

LGTM.

lib/LTO/ThinLTOCodeGenerator.cpp
214 ↗(On Diff #99631)

Can you mention in the comment that we're doing it in order to strip invalid debug info that could have been imported in the process?

This revision is now accepted and ready to land.May 19 2017, 4:39 PM
This revision was automatically updated to reflect the committed changes.