This is an archive of the discontinued LLVM Phabricator instance.

Handle the verifier at run() time in the PassManager instead of build time
ClosedPublic

Authored by mehdi_amini on Nov 2 2020, 10:21 PM.

Details

Summary

This simplifies a few parts of the pass manager, but in particular we don't add as many
verifierpass as there are passes in the pipeline, and we can now enable/disable the
verifier after the fact on an already built PassManager.

Diff Detail

Event Timeline

mehdi_amini created this revision.Nov 2 2020, 10:21 PM
mehdi_amini requested review of this revision.Nov 2 2020, 10:21 PM

You should probably note somewhere that this changes the default behavior of the pass manager to not verify passes by default.

mlir/lib/Pass/Pass.cpp
356–357

unrelated nit: This should just return the error directly.

397

Should we hoist this above the instrumentation calls? I'm inclined to say yes.

398

Why? Do we intend to treat cases where a pass accidentally changes something outside of the current operation as UB? It'd still be nice to get verifier failures when my, e.g., function pass does something that it shouldn't.

483

Is there a double space after 'on'?

512–513

unrelated nit: Can you remove this auto while you are here?

745–748

?

mehdi_amini added inline comments.Nov 2 2020, 11:02 PM
mlir/lib/Pass/Pass.cpp
397

I wasn't sure, the current version preserve the existing behavior I believe, but I'm happy to move it above as well!

Wouldn't it mess up things like pass timing by including the verifier into it?

398

Not sure I understand? I added this check because I though that the last pass in the OpToOpPassAdaptor pipeline would already have verified the IR.

Is this a nesting question: an extra verifier at this level would check a level above maybe?

rriddle accepted this revision.Nov 2 2020, 11:09 PM
rriddle added inline comments.
mlir/lib/Pass/Pass.cpp
397

I wasn't sure, the current version preserve the existing behavior I believe, but I'm happy to move it above as well!

Wouldn't it mess up things like pass timing by including the verifier into it?

Yeah, I think it goes either way. I would expect several instrumentations to benefit from the fact that the pass fails when the verifier fails, i.e. it would be easier to track down which pass caused a specific failure. Pass instrumentation would hurt more, but I think that one can be explained away as similar to "do you profile in debug mode?". If pass timing is the one negative hit, which was the only one I could think of, then I'd want to move it. Unless you can think of others that might be negatively impacted?

398

Sorry, yes it is a nesting thing. I'd still want us to verify the parent module after running a nested pipeline on it.

This revision is now accepted and ready to land.Nov 2 2020, 11:09 PM
rriddle added inline comments.Nov 2 2020, 11:28 PM
mlir/include/mlir/Pass/PassManager.h
151–152

This comment needs to be updated.

mehdi_amini marked 9 inline comments as done.

Address River's comments

mehdi_amini added inline comments.Nov 3 2020, 12:59 AM
mlir/lib/Pass/Pass.cpp
789

You should probably note somewhere that this changes the default behavior of the pass manager to not verify passes by default.

Did you miss the default value for verifyPasses here?

rriddle added inline comments.Nov 3 2020, 1:44 AM
mlir/lib/Pass/Pass.cpp
789

I most certainly did.