Chris Dodd
Chris Dodd
> At the very least, it should be clearly documented that this pass is only correct if side effects ordering is enabled. I did put comments to that effect in...
> I agree, someone could be disabling SEO now and then they will not read the documentation. Still I would say `BUG_CHECK` for combination in frontend is in order, as...
> > * [Support for op= assignments in the frontend/midend #5108 (comment)](https://github.com/p4lang/p4c/pull/5108#discussion_r1972150882) > > * the case of booleans: there is asymmetry here as booleans only support `&&`, `||` and...
So it seems that something like if (condition_that_is_always_true) @likely { ...some code... } is quite plausible, and if the compiler can prove it is always true and remove the `if`,...
So I've added warnings for always taken/@unlikely and never taken/@likely branches and a testcase. Overall, I think this is ready to go -- do we need more discussion in the...
@asl @fruffy @vlstill @jafingerhut -- is it possible to get a review/approval for this?
> Summary: This looks reasonable to me. I think the `if (true) @unlikely` warning should be added in this PR, the rest can be probably done later (including the `select`...
I think this PR is ready to go, except for discussion on what should and should not be a warning. @asl, @vlstill what do you think?
@fruffy @jafingerhut -- can I get approval for this PR?
I commented out the warning for @unlikely on always taken blocks. Unfortunately looks like all the CI is broken currently