Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mlir] Do not set lastToken in AsmParser's resetToken function #290

Merged
merged 3 commits into from
Aug 21, 2024

Conversation

jorickert
Copy link

@jorickert jorickert commented Aug 20, 2024

The member lastToken is the last token that was consumed by the parser. Resetting the lexer position to a different position does not cause any token to be consumed, so lastToken should not be updated. Setting it to curToken can cause the end location of OperationDefinition to be off-by-one, pointing to the first token after the operation.

An example for an operation for which the scopeLoc.end location was wrong before is:
%0 = torch.vtensor.literal(dense_resource<elided> : tensor<768xbf16>)
: !torch.vtensor<[768],bf16> . Here the scope end loc always pointed to the next token

@jorickert
Copy link
Author

I plan to upstream this

The member lastToken is the last token that was consumed by the parser.
Resetting the lexer position to a different position does not cause any token to
be consumed, so lastToken should not be updated. Setting it to curToken can
cause the scopeLoc.end location of OperationDefinition to be off-by-one, pointing to the
first token after the operation.

An example for an operation for which the scopeLoc.end location was wrong before is:
%0 = torch.vtensor.literal(dense_resource<__elided__> : tensor<768xbf16>)
 : !torch.vtensor<[768],bf16> . Here the scope end loc always pointed to the next token
@jorickert jorickert force-pushed the jrickert.parse_end_loc branch from f7cc773 to f357780 Compare August 20, 2024 12:21
@mgehre-amd
Copy link
Collaborator

Can you please add a test case to show the improvement?

@cferry-AMD
Copy link
Collaborator

LGTM, per here this lastToken is assumed to have been parsed, which resetting the pointer doesn't affect. With the test case things should be good :)

@jorickert
Copy link
Author

@mgehre-amd Added a test

@jorickert jorickert requested a review from mgehre-amd August 21, 2024 11:34
@jorickert jorickert force-pushed the jrickert.parse_end_loc branch from e363f41 to 5193e67 Compare August 21, 2024 11:41
Copy link
Collaborator

@mgehre-amd mgehre-amd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

This test checks the parsed ops' locations and scope locations.
It uses the !llvm.array type in the test to check that locations are correct for
ops that contain an extended-type.
The parser for extended-types calls resetToken, which caused wrong locations in
the past.
This getter is can easily be confused with the similar named
allowUnregisteredDialects setter
@jorickert jorickert force-pushed the jrickert.parse_end_loc branch from 5193e67 to 5f083d4 Compare August 21, 2024 13:28
Copy link
Collaborator

@cferry-AMD cferry-AMD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jorickert jorickert merged commit c9a2f85 into feature/fused-ops Aug 21, 2024
4 checks passed
@jorickert jorickert deleted the jrickert.parse_end_loc branch August 21, 2024 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants