Open kfcripps opened 1 week ago
It's not actually that it considers sliced assignments to be "reads" -- its that it considered sliced assignments to not replace all previous writes to the variable. Fixing this would require tracking each bit of each variable individually, instead of just tracking the variable as a whole.
its that it considered sliced assignments to not replace all previous writes to the variable.
My understanding is that the way it does this is by marking the slice assignment as a "read" of the sliced l-value, so that previous assignments to the same l-value will not be removed: https://github.com/p4lang/p4c/blob/main/frontends/p4/simplifyDefUse.cpp#L1396-L1402
As a side-effect, we get this superfluous warning.
Fixing this would require tracking each bit of each variable individually, instead of just tracking the variable as a whole.
I agree, that's basically what needs to be done for this issue. I spent some time trying something like this but I gave up as I couldn't get it to work initially and didn't want to spend anymore time working on it.
Fixing this would require tracking each bit of each variable individually, instead of just tracking the variable as a whole.
Alternatively, we can just be conservative in SimplifyDefUse
(but the current behavior of treating writes as reads is too conservative):
SliceTracker
logic should be moved to its own separate pass (this is where we can more carefully track each read/written bit individually)
Building the following P4 program:
results in the following warning:
It doesn't make sense to print this kind of warning about a write to an uninitialized field. The code in
SimplifyDefUse
considers these assignments to "read" the sliced l-valuef
, but this is a gross hack and the logic should be rewritten in a more sensible way. Doing so should result in this unhelpful warning going away.A similar problem was recently fixed in the
ParsersUnroll
pass: https://github.com/p4lang/p4c/pull/4948