Skip to content

Fix issue: annotations get optimized out.#328

Open
vaalfreja wants to merge 1 commit into
p4lang:mainfrom
vaalfreja:anno
Open

Fix issue: annotations get optimized out.#328
vaalfreja wants to merge 1 commit into
p4lang:mainfrom
vaalfreja:anno

Conversation

@vaalfreja
Copy link
Copy Markdown
Collaborator

Fix the issue when annotations gets optimized out from empty blocks when canonicalizer or any recursive pass is run.

Comment thread lib/Dialect/P4HIR/P4HIR_Ops.cpp Outdated
void P4HIR::ScopeOp::getEffects(
SmallVectorImpl<SideEffects::EffectInstance<MemoryEffects::Effect>> &effects) {
if (getAnnotations()) {
effects.emplace_back(MemoryEffects::Write::get(), ExternResource::get());
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I am not quite sure this is semantically correct... After all, there no extern calls there. Also, you'd definitely want to reason about some annotations, e.g. the builtin ones: https://p4.org/wp-content/uploads/sites/53/p4-spec/docs/p4-16-working-draft.html#sec-branch-annotations

Copy link
Copy Markdown
Collaborator Author

@vaalfreja vaalfreja Mar 18, 2026

Choose a reason for hiding this comment

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

We can probably remove @ atomic empty block, since nothing is atomic.
Branch annotations are for IfOps not ScopeOp
@ NoWarn should stay - default behavior
Other are not for scopes afaik

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

IfOp annotations could become ScopeOp ones in case of constant true / false condition.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

It doesn't become scopeOp it just becomes basic block after flattening, we don't preserve annotations when it happen though and we probably should. Unlikely probably not, if it isn't a branch unlikely doesn't make sense but custom annotations probably should be saved..

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I am not talking about flattening. I'm talking this kind of transformation:

if (true) {
  ...
}

should become

{
...
}

with annotations preserved.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

We didn't canonicalize that, but now we do, I've moved likely/unlikely logic there also because it doesn't make sense to have a scope with a branch hint - it's not a branch.

@asl
Copy link
Copy Markdown
Collaborator

asl commented Apr 13, 2026

@vaalfreja Btw, it would help if the commit messages would be more meaningful. So instead of "what" you did, "why". Similar to https://xyproblem.info/ :) Remember when we're not squashing commits, but rebasing them, then original commit message is used.

@vaalfreja
Copy link
Copy Markdown
Collaborator Author

@vaalfreja Btw, it would help if the commit messages would be more meaningful. So instead of "what" you did, "why". Similar to https://xyproblem.info/ :) Remember when we're not squashing commits, but rebasing them, then original commit message is used.

Fixed it, sorry misunderstood which particular message you meant last time.

…s when canonicalizer or any recursive pass is run.

2. Optimize out empty if/else branches in canonicalizer.

Signed-off-by: Julia Koval <c_yuliak@xsightlabs.com>
@fruffy fruffy requested a review from asl April 17, 2026 18:42
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.

2 participants