Skip to content

Add support for compound assignment operators#3669

Closed
rst0git wants to merge 1 commit into
p4lang:mainfrom
rst0git:compound-assignment-operators
Closed

Add support for compound assignment operators#3669
rst0git wants to merge 1 commit into
p4lang:mainfrom
rst0git:compound-assignment-operators

Conversation

@rst0git

@rst0git rst0git commented Nov 6, 2022

Copy link
Copy Markdown
Member

This pull request adds support for compound assignment expressions of the form E1 op= E2 as discussed in p4lang/p4-spec#1144 and p4lang/p4-spec#1139.

Fixes #3258

This patch adds support for compound assignment expressions
of the form `E1 op= E2`.

Signed-off-by: Radostin Stoyanov <radostin.stoyanov@eng.ox.ac.uk>
@rst0git rst0git requested a review from mihaibudiu November 6, 2022 04:27
$1, $3, $6);
$$ = new IR::MethodCallStatement(@1 + @7, mc); }

| lvalue "+=" expression ";"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I am not sure this is the right semantics. This implementation will repeat the side effects on the lhs twice.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Note most lvalue by definition could not have a side effect.
The only one which I can think of is: headerstack[f(a)].b where f is defined to take 1 arguments which is inout (you could do something similar with externs too).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

regardless of the inout arguments, a method call may have arbitrary side effects within in, and the way this code duplicates the reference to the lhs, a method call inside an index would end up being called twice. We have a pass (DoSimplifyExpressions) that exists to deal with this kind of program, but there are a number of other passes that currently must run before it (such as typeChecking) that would need to understand what is going on. So this almost certainly needs a new IR node type (some kind of op-assignment statement) to represent this until SimplifyExpressions can turn it into a normal AssignmentStatement, and all the passes that run before need to know about it.

@jnfoster

jnfoster commented Nov 7, 2022

Copy link
Copy Markdown

We will need to be careful if we want to ensure that l-values never have side effects. I am not even sure that's true of the current language design and it would be fragile to ensure it going forward.

@jnfoster

jnfoster commented Jun 5, 2023

Copy link
Copy Markdown

@rst0git are you still interested in completing this feature? Do you need help with the p4c implementation?

@jnfoster

Copy link
Copy Markdown

@rst0git, can you let us know if you are still working on this? We'd be glad to see it added, but need to fix the side-effect issue...

@rst0git

rst0git commented Aug 29, 2023

Copy link
Copy Markdown
Member Author

@jnfoster I'm sorry for the delayed response. I will update the pull request in the next few days.

@ChrisDodd

Copy link
Copy Markdown
Contributor

Superceeded by #5108

@ChrisDodd ChrisDodd closed this Jan 22, 2025
@rst0git rst0git deleted the compound-assignment-operators branch January 23, 2025 08:56
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.

Addition assignment (+=) operator

5 participants