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

Make sure P4 expression optimization does not strip away types #4300

Merged
merged 8 commits into from
Jan 8, 2024

Conversation

vlstill
Copy link
Contributor

@vlstill vlstill commented Dec 19, 2023

Fixes this error:

Internal error: In file: ./p4c/backends/p4tools/modules/testgen/lib/continuation.cpp:124
P4Testgen Bug: Continuation v; has parameter of type bit<32>, but was given an argument (|*packetLen_bits(bit<32>)| >> 3) + 4294967238; of type <Type_Unknown>(2)

Which is caused by P4::optimizeExpression not preserving type when changing x - CONST to x + (-CONST).

The change is mainly in two passes: ConstantFolding and StrengthReduction -- I've tried to make sure the types of expressions are preserved by these passes. I've also added propagation of source info to a few places.

@vlstill vlstill changed the title [P4Testgen] Make sure the values in the state are all typed Make sure P4 expression optimization does not strip away types Dec 19, 2023
@vlstill vlstill added bug This behavior is unintended and should be fixed. p4tools Topics related to the P4Tools back end core Topics concerning the core segments of the compiler (frontend, midend, parser) labels Dec 19, 2023
@vlstill vlstill self-assigned this Dec 19, 2023
@vlstill vlstill marked this pull request as ready for review January 3, 2024 13:22
@vlstill vlstill requested a review from fruffy January 3, 2024 13:22
backends/p4tools/common/lib/symbolic_env.cpp Outdated Show resolved Hide resolved
backends/p4tools/common/lib/symbolic_env.cpp Outdated Show resolved Hide resolved
backends/p4tools/common/lib/symbolic_env.cpp Outdated Show resolved Hide resolved
@@ -37,7 +37,9 @@ std::vector<std::pair<IR::StateVariable, const IR::Expression *>> ExprStepper::s
ExecutionState &nextState, const std::vector<IR::StateVariable> &flatFields,
int varBitFieldSize) {
std::vector<std::pair<IR::StateVariable, const IR::Expression *>> fields;
for (const auto &fieldRef : flatFields) {
// Make a copy of the StateVariable so it can be modified in the varbit case (and it is just a
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, in this case we are making a copy for the common case (no Varbit). Is that really better?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is quite small class (one pointer + vptr) so I'd say this does not matter either way. Could be even better since there will be no dereference, but could be also exactly the same if the optimizer is smart enough (I haven't checked).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah I think that is a check we should keep in this particular setter. The other code can be moved out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm confused, you have presubmably replied to a different thread, did you mean that the check for type being set in the expression should be (also) in SymbolicEnv::set?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, the comment was meant for #4300 (comment). Not sure what happened.

@@ -28,7 +27,7 @@ const IR::Expression *SymbolicEnv::get(const IR::StateVariable &var) const {
bool SymbolicEnv::exists(const IR::StateVariable &var) const { return map.find(var) != map.end(); }

void SymbolicEnv::set(const IR::StateVariable &var, const IR::Expression *value) {
map[var] = P4::optimizeExpression(value);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we remove the optimization, I'm not sure if the check if type is set should be here too? May not be necessary for all tools that use SymbolicEnv.

@@ -37,7 +37,9 @@ std::vector<std::pair<IR::StateVariable, const IR::Expression *>> ExprStepper::s
ExecutionState &nextState, const std::vector<IR::StateVariable> &flatFields,
int varBitFieldSize) {
std::vector<std::pair<IR::StateVariable, const IR::Expression *>> fields;
for (const auto &fieldRef : flatFields) {
// Make a copy of the StateVariable so it can be modified in the varbit case (and it is just a
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah I think that is a check we should keep in this particular setter. The other code can be moved out.

@vlstill vlstill merged commit d7dfee1 into p4lang:main Jan 8, 2024
13 checks passed
@vlstill vlstill deleted the fix-state-types branch January 8, 2024 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This behavior is unintended and should be fixed. core Topics concerning the core segments of the compiler (frontend, midend, parser) p4tools Topics related to the P4Tools back end
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants