This is an archive of the discontinued LLVM Phabricator instance.

Add a `-verify-roundtrip` option to `mlir-opt` intended to validate custom printer/parser completeness
ClosedPublic

Authored by mehdi_amini on Oct 23 2020, 7:30 PM.

Details

Summary

Running:

MLIR_OPT_CHECK_IR_ROUNDTRIP=1 ninja check-mlir

will now exercises all of our test with a round-trip to bytecode and a comparison for equality.

Diff Detail

Event Timeline

mehdi_amini created this revision.Oct 23 2020, 7:30 PM
Herald added a project: Restricted Project. · View Herald Transcript
mehdi_amini requested review of this revision.Oct 23 2020, 7:30 PM

I wonder if we should just make it the default?

ftynse accepted this revision.Oct 26 2020, 10:42 AM
ftynse added inline comments.
mlir/lib/Support/MlirOptMain.cpp
92 ↗(On Diff #300448)

Do we want to still run passes in this case? I'd just return doVerifyRoundTrip if the flag is set.

This revision is now accepted and ready to land.Oct 26 2020, 10:42 AM

D90179 should fix the bug this found

rriddle accepted this revision.Oct 26 2020, 11:27 AM
rriddle added inline comments.
mlir/lib/Support/MlirOptMain.cpp
50 ↗(On Diff #300448)

Can you emit an error here to give context(i.e. that these errors are from round trip) to the errors that may come out of parseSourceString?

64 ↗(On Diff #300448)

nit: Add braces here, or move the comment.

65 ↗(On Diff #300448)

nit: failed to round-trip resultant IR?

87 ↗(On Diff #300448)

Why the newline here?

I wonder if we should just make it the default?

IMO, it depends on the user running mlir-opt. If I'm iterating locally, I generally wouldn't want these additional cost/complexity of running this. For tests that run automatically, that default is probably fine. I would strongly prefer that we keep mlir-opt defaults useful for users iterating locally and generally using mlir-opt as a development tool. For testing, could we just have another frontend(alias of mlir-opt?) that has better defaults for testing use cases? We've had conversations of sane defaults in the past, and it seems like the truly contentious ones always have this divide between local development and testing.

I wonder if we should just make it the default?

IMO, it depends on the user running mlir-opt. If I'm iterating locally, I generally wouldn't want these additional cost/complexity of running this. For tests that run automatically, that default is probably fine. I would strongly prefer that we keep mlir-opt defaults useful for users iterating locally and generally using mlir-opt as a development tool. For testing, could we just have another frontend(alias of mlir-opt?) that has better defaults for testing use cases? We've had conversations of sane defaults in the past, and it seems like the truly contentious ones always have this divide between local development and testing.

I'd also be pro not making it default from orthogonality point of view. Having all tests verifying printing/parsing vs having dedicated tests seems a wrong tradeoff. Yes having it default would catch cases not covered, but the fact that they aren't covered by unit tests is the problematic part that has to be addressed IMHO.

mlir/include/mlir/Support/MlirOptMain.h
47 ↗(On Diff #300448)

I don't know at which point we refactor this into a options struct, but 6 bools in a row is quite easy to mess up.

mlir/lib/Support/MlirOptMain.cpp
40 ↗(On Diff #300448)

Nit: this need not verify custom, depending on other flags passed (unless you set generic form to false on first print I believe the command line option for whether set or not takes preference) this just verifies printing and parsing.

77 ↗(On Diff #300448)

Mmm, we now have 3 bools in a row here, thats a bit error prone

92 ↗(On Diff #300448)

Or potentially rename to alsoVerifyRoundTrip to avoid confusion?

206 ↗(On Diff #300448)

Roundtrip

nicolasvasilache resigned from this revision.Jul 28 2021, 2:14 AM

Rebase (WIP)

Add support for bytcode, fix location management which also uncover issues with singleblockimplicitterminator dropping locations :(

Rebase and use bytecode

Fix a bug that prevented round-trip from actually runnning with bytecode!

mehdi_amini edited the summary of this revision. (Show Details)May 24 2023, 10:18 PM
mehdi_amini edited the summary of this revision. (Show Details)

Perform round-trip in a new context to avoid issues with resource handles

jpienaar accepted this revision.May 25 2023, 4:50 AM

Looks good to help flushing these issues out.

mlir/lib/Tools/mlir-opt/MlirOptMain.cpp
124

roundtripped module differs from reference? (The above are also errors in roundTrip testing)

mlir/test/lit.cfg.py
131 ↗(On Diff #525480)

Is else needed?

mehdi_amini marked an inline comment as done.May 25 2023, 3:11 PM
mehdi_amini added inline comments.
mlir/lib/Support/MlirOptMain.cpp
87 ↗(On Diff #300448)

Got there in a rebase/conflict fixing.

92 ↗(On Diff #300448)

It seems less surprising to me to run passes the user would have specified than silently ignore them?
(We could also error out if passes are provided, but we don't for -verifyDiagnostic I think)

mlir/test/lit.cfg.py
131 ↗(On Diff #525480)

I don't know what happens if we put mlir-opt twice here. That said I think listing our tools in the tools has no effect right now when we don't substitute

This revision was landed with ongoing or failed builds.May 25 2023, 3:16 PM
This revision was automatically updated to reflect the committed changes.