This is an archive of the discontinued LLVM Phabricator instance.

[AsmParser/Printer] Rework sourceloc support for function arguments.
ClosedPublic

Authored by lattner on Apr 21 2022, 10:43 AM.

Details

Summary

When Location tracking support for block arguments was added, we
discussed various approaches to threading support for this through
function-like argument parsing. At the time, we added a parallel array
of locations that could hold this. It turns out that that approach was
verbose and error prone, roughly no one adopted it.

This patch takes a different approach, adding an optional source
locator to the UnresolvedOperand class. This fits much more naturally
into the standard structure we use for representing locators, and gives
all the function like dialects locator support for free (e.g. see the
test adding an example for the LLVM dialect).

Diff Detail

Event Timeline

lattner created this revision.Apr 21 2022, 10:43 AM
lattner requested review of this revision.Apr 21 2022, 10:43 AM

We discussed this in some other patch that I lost track of, this was just something on my deep todo list.

rriddle accepted this revision.Apr 21 2022, 11:15 AM

Much much better, thanks for doing this!

mlir/lib/Parser/Parser.cpp
1276
This revision is now accepted and ready to land.Apr 21 2022, 11:15 AM
lattner marked an inline comment as done.Apr 21 2022, 12:43 PM
lattner updated this revision to Diff 424271.Apr 21 2022, 12:43 PM

Add missing blank line

This revision was landed with ongoing or failed builds.Apr 21 2022, 12:43 PM
This revision was automatically updated to reflect the committed changes.

Thank you for the quick review!

mehdi_amini added inline comments.Apr 25 2022, 11:05 AM
mlir/lib/Parser/Parser.cpp
1278

We've got internal report that now "foo %x loc(...) now assigns the loc to %x instead of foo" and it breaks custom parsers, thoughts?

lattner added inline comments.Apr 25 2022, 9:06 PM
mlir/lib/Parser/Parser.cpp
1278

No good deed goes unpunished :-) I'll look into it!

lattner added inline comments.Apr 25 2022, 10:44 PM
mlir/lib/Parser/Parser.cpp
1278

WDYT about this approach (cc @rriddle):

  1. Revert parseOperand back to not parsing the location information. Doing so will cause a bunch of ambiguities like this because we parse "%foo" in lots of contexts.
  2. Introduce a new "parseArgument" parser hook that parses the typical %42 : loc(...) type { attrs } grammar used by function-signature-like things.
  3. parseArgument would fill in a new ResolvedArgument struct, instead of UnresolvedOperand since it has the type it can resolve, and this will also hold the attributes and source loc.

I think this will restore compatibility, capture an important and pervasive pattern with a first class API that we always reimplement all over the place, and would allow us to add ODS support for this pattern in a nice way (but I'm not volunteering to do that, I don't know ODS internals well enough).

WDYT? If you both find this approach to be promising, then I'll try to get a PR up tomorrow.

Mehdi if this patch is causing a problem for you, please feel free to revert while we figure this out.

rriddle added inline comments.Apr 25 2022, 10:46 PM
mlir/lib/Parser/Parser.cpp
1278

The overall approach SGTM.

csigg added inline comments.Apr 26 2022, 7:32 AM
mlir/lib/Parser/Parser.cpp
1278

Mehdi if this patch is causing a problem for you, please feel free to revert while we figure this out.

No need to revert. I think the only test that started failing is this one and I just switched to -mlir-print-op-generic to work around it for now.

Sweet, I'll get on this in a few minutes, thx!