This is an archive of the discontinued LLVM Phabricator instance.

[AsmParser] Rework logic around "region argument parsing"
ClosedPublic

Authored by lattner on Apr 26 2022, 12:03 PM.

Details

Summary

The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supposed to allow a result number like #3).

Unfortunately the implementation has two problems:

  1. It didn't actually check for the result number and reject it. parseRegionArgument and parseOperand were identical.
  2. It had a lot of machinery built up around it that paralleled operand parsing. This also was functionally identical, but also had some subtle differences (e.g. the parseOptional stuff had a different result type).

I thought about just removing all of this, but decided that the
missing error checking was important, so I reimplemented it with
a allowResultNumber flag on parseOperand. This keeps the
codepaths unified and adds the missing error checks.

Diff Detail

Event Timeline

lattner created this revision.Apr 26 2022, 12:03 PM
lattner requested review of this revision.Apr 26 2022, 12:03 PM
lattner added inline comments.Apr 26 2022, 12:30 PM
mlir/include/mlir/IR/OpImplementation.h
1126

incidentally, I think it makes sense to remove requiredOperandCount at this point. The original usecase was for things like binary operators that had two operands, but these get broken out into explicit parseOperand calls these days. This isn't related to this patch though.

lattner updated this revision to Diff 425284.Apr 26 2022, 12:32 PM

Update flang

Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 12:32 PM
rriddle accepted this revision.Apr 27 2022, 8:43 AM

I'm LGTM on the idea of removing the internal special casing, but the loss of parseRegionArgument as a user facing API leads to a loss in code readability IMO. I'd rather keep that API and properly forward to parseOperand.

mlir/include/mlir/IR/OpImplementation.h
1248

Can we keep retain these methods as a non-virtual API that clear forwards to parseOperand with the allowResultNumber flag set to false?

This revision is now accepted and ready to land.Apr 27 2022, 8:43 AM
lattner added inline comments.Apr 27 2022, 9:12 AM
mlir/include/mlir/IR/OpImplementation.h
1248

Well sure, that's possible. I'm trying to do three things with this patch:

  1. Fix a bug, implement checking that should have been there forever.
  2. Reclaim the name "Argument": "Region arguments" as a thing doesn't really make sense as a name for this, and I'm going to be introducing a first class "Argument" concept which is different.
  3. Reduce unneeded API surface area.

I agree that #3 isn't essential, but part of the reason that deleting it made sense to me is that the names were meaningless (regions don't have arguments, blocks do) and uncorrelated to the behavior (well, ok, there was no behavior before).

Is there a better name for what this is? Maybe renaming it would improve the situation. I still don't like having parallel parseRegionArgumentList versions, but that too could be improved by dropping the unused requiredOperandCount variant.

rriddle added inline comments.Apr 27 2022, 9:22 AM
mlir/include/mlir/IR/OpImplementation.h
1248

The problem with the patch as-is though, as it pertains to #3, is that the current parseRegionArgument* API is for a different class of things than parseOperand. They are generally used for the arguments of the entry block of a region (and in that sense the name RegionArgument does make sense, given that you pass the arguments when parsing a region; see parseRegion just above). It's essentially parsing a definition of a single SSA value. The exposure of allowResultNumber feels somewhat low level and obfuscates what the parser code is doing. "I'm parsing an argument to be passed to a region entry block" vs "I'm parsing an operand that can't have a result number"? The second one doesn't immediately click for me that its for a block argument.

rriddle added inline comments.Apr 27 2022, 10:49 AM
mlir/include/mlir/IR/OpImplementation.h
1248

What did you have in mind/intend for the "Argument" concept? I would expect that to subsume the RegionArgument stuff if it's intended for what the name suggests.

lattner added inline comments.Apr 27 2022, 12:32 PM
mlir/include/mlir/IR/OpImplementation.h
1248

Argument is the "ssa name + type + attr list + source loc" package. "RegionArgument" is just a limited form of SSA name. They're pretty different.

rriddle added inline comments.Apr 27 2022, 12:35 PM
mlir/include/mlir/IR/OpImplementation.h
1248

In what situations do you want to use that Argument concept?

River and I discussed this offline, I'm going to land this and build on it. Thx!

This revision was automatically updated to reflect the committed changes.