This is an archive of the discontinued LLVM Phabricator instance.

[mlir][scf] Fix builder of WhileOp with region builder arguments.
ClosedPublic

Authored by ingomueller-net on Jan 30 2023, 10:54 PM.

Details

Summary

The overload of WhileOp::build with arguments for builder functions for
the regions of the op was broken: It did not compute correctly the types
(and locations) of the region arguments, which lead to failed assertions
when the result types were different from the operand types.
Specifically, it used the result types (and operand locations) for *both*
regions, instead of the operand types (and locations) for the 'before'
region and the result types (and loecations) for the 'after' region.

Diff Detail

Event Timeline

ingomueller-net requested review of this revision.Jan 30 2023, 10:54 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2023, 10:54 PM

I am not sure about whether this is the right form of testing the op. Note that the unit test crashes with a failed assertion if SCF.cpp isn't changed. I don't think that a lit test with an .mlir file would do the trick because it doesn't exercise that builder. If anyone has a better idea, please let me know.

mlir/lib/Dialect/SCF/IR/SCF.cpp
2771

Note that I am not sure whether these are the right locations. Do the arguments originate from the *operands* of the while loop or from the while loop itself? (In the latter case, this would have to be odsState.location, I guess.)

mehdi_amini added inline comments.Jan 31 2023, 4:44 PM
mlir/unittests/Dialect/SCF/BuildersTest.cpp
74 ↗(On Diff #493488)

Is there a test-pass that could get this code? (and as such run it as a lit test)

mlir/unittests/Dialect/SCF/BuildersTest.cpp
74 ↗(On Diff #493488)

git grep WhileOp -- mlir/test/ does not yield any results, and the three test passes for SCF (test-scf-for-utils, test-scf-if-utils, and test-scf-pipelining) test specific utility functions. In both cases, I don't see how I could piggy back my check onto something existing.

I *could* write a test pass that exercises that builder, though, if people think that that's more elegant. What would it do? Walk over all WhileOps and replace each of them with an identical copy using the builder in question?

Another possibility is to modernize some (non-test) code to use that builder. One possible place is this one in the ForToWhileLoop transform. That has certainly the lowest testing footprint but also the risk of the builder not being tested anymore if that code is refactored. Also note that this usage of the builder does not seem to trigger the bug, so just using the builder somewhere isn't a guarantee to test it properly.

I guess I can mitigate both problems by modernizing all other places I can find, such as this one, this one, and up to seven more in two transforms of SparseTensor.

What do people think?

mehdi_amini added inline comments.Feb 1 2023, 10:00 AM
mlir/unittests/Dialect/SCF/BuildersTest.cpp
74 ↗(On Diff #493488)

. What would it do? Walk over all WhileOps and replace each of them with an identical copy using the builder in question?

Technically, it could just do exactly the same thing as what you're doing here: take a module, build a while loop into it, and that's it.

The reason for preferring lit test is mostly uniformity with the codebase, and historically the fact that it involved linking a single mlir-opt binary instead of relinking many unit-tests binaries (saving time and disk space). I'm not sure if this tradeoff is still valid with modern machines though, I frequently felt that C++ unit-tests allowed for more "targeted" checks that were a bit convoluted with FileCheck. Our test passes sometimes are in this category as well: printing "breadcrumbs" that are intended to be matched by FileCheck.

Here is one reference: https://lists.llvm.org/pipermail/llvm-dev/2020-June/142932.html

Implement test as a test pass rather than googletest-based unittest.

This implements the suggestion by @mehdi_amini, which I think works nicely here.

@mehdi_amini, thanks a lot for the explanations and the suggestion!

mehdi_amini accepted this revision.Feb 2 2023, 10:03 AM
This revision is now accepted and ready to land.Feb 2 2023, 10:03 AM
Mogball accepted this revision.Feb 2 2023, 10:19 AM

I think a unit test would've been more appropriate in this case, but LGTM

I think a unit test would've been more appropriate in this case, but LGTM

I don't disagree, but we don't have precedent to unit-test the builders, do we? Maybe we should change our "policy" (more "existing practice") on unit-tests? Worth a discourse proposal if you're motivated :)

I don't have a strong opinion either way. I'll wait until Monday and then land, unless somebody tells me not to.

Build failed due to presumably unrelated problem. Rebasing to trigger a rebuild.