This is an archive of the discontinued LLVM Phabricator instance.

Update mlir GDB printers
ClosedPublic

Authored by csigg on Jan 5 2022, 2:42 AM.

Details

Summary

Update prettyprinters.py to match MLIR changes.

This has gone unnoticed because no build bot is running tests with debug info.

I will look into what we can do about this separately. There is
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/,
from Apple. The Debug Info tests are failing despite the green result.

See https://github.com/llvm/llvm-project/issues/48872.

Note: the llvm-support.gdb test only works with Debug,
but not RelWithDebInfo because some checked symbols are stripped.

Diff Detail

Event Timeline

csigg created this revision.Jan 5 2022, 2:42 AM
csigg requested review of this revision.Jan 5 2022, 2:42 AM
dblaikie accepted this revision.Jan 5 2022, 1:09 PM

I don't have a very high bar for this - if you're the only one currently using/interested in the MLIR GDB pretty printers, should probably feel free to commit changes without review. I don't have enough context for MLIR to offer any nuanced review - just some general/relatively uninformed ideas about general code/test style, etc. (welcome to send them for review & I can provide that if it's useful to you, though)

cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.gdb
25–28

while you're refactoring this file anyway, might it make sense to put the actual command before the CHECKs? More like the way assertions are done in a gunit test, etc? (that way the reader isn't looking ahead to see what command is being run to figure out why these CHECKs are the right ones)

47–50

Is this all the output? Is it on one line or multiple, is there any punctuation separating the fields/values?

Might be worth using CHECK-SAME or CHECK-NEXT depending on whether it's on one line or multiple, and if there's other punctuation, etc, I think I'd prefer to see that in the check to make it clear how this renders to a user. (because, at least to me/as it stands, it seems a bit ad-hoc - I'm not sure I'd know how to read that output/what to make of it - at least maybe I'd expect each part to have a "x = y" form, maybe)

Similarly for some of the other type dumps here.

This revision is now accepted and ready to land.Jan 5 2022, 1:09 PM
csigg updated this revision to Diff 397957.Jan 6 2022, 11:58 AM

Move CHECK statements after print.

csigg marked an inline comment as done.Jan 6 2022, 1:14 PM

Thanks David for the review, I appreciate your input.

cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.gdb
25–28

Yes, that makes sense. Thanks for the suggestion.

47–50

This change adds set pretty print on, which makes gdb print on multiple lines. The CHECKs also work with off (single-line print outputs), but failures become harder to read. The CHECK-LABELs guarantee that all CHECKs apply to a single print statement.

Is this all the output?

No, the output is much much larger than this. The pretty printers here do no try to trim the output, but rather show more information (e.g., print the mlir::Value::impl pointee as well). See the attached file.

The CHECKs only verify that the essential information is in the output, and are not intended to "make it clear how this renders to a user". I think doing so would make the test quite brittle wrt to mlir code changes.

This revision was automatically updated to reflect the committed changes.
csigg marked an inline comment as done.
dblaikie added inline comments.Jan 6 2022, 7:08 PM
cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.gdb
47–50

Ah, thanks for the context! I see, so in this case as an example (UnrankedMemRef) it prints the typeID, then it casts down to the concrete type and returns that back for gdb generic pretty printing? (hmm, actually I guess that isn't generic printing - the "members of" isn't how gdb is printing some simple examples of derived classes I'm looking at, for instance)

I'd probably add a bit more structure to the checks myself, even if it's not every line of output. (like I'd probably test the whole "typeID = " line, so this wouldn't match some other mention of UnrankedMemRefType in the rest of the output, possibly - which could make for hard to diagnose FileCheck failures in the future - possibly using CHECK-NEXT, again, to constrain the expectation a bit. Beyond that, if the rest of that is using some generic pretty printing functionality - yeah, maybe there's not much to it & checking some members you know are unique to the downcasted type is about right. Maybe just looking for the "members of type " line would be adequate, then)

But no worries - whatever you find works best for you in this case I expect will be OK.