Remove unneed UBOUNDED_MAX checks #287
Conversation
For the case of COMP, if type_dag[COMP_B(...)].bitSize exceeds UNBOUNDED_MAX, then the bounded_add and friends functions will already set extraCellsBound[0] and extraCellsBound[1] to UBOUNDED_MAX. Therefore the branch doesn't have any computational effect. It is also not a case worth optimizing for. The case of DISCONNECT is similar, however possibly only one of extraCellsBound[0] or extraCellsBound[1] will end up being set to UBOUNDED_MAX instead of both. This is fine, because these values are just intermediate values for the *cellsBound computation at the end of the function. There we take the bounded_max of both the extraCellsBound[0] and extraCellsBound[1] functions. So the result is the same whether or not both extraCellsBound values are maxed out or only one is.
How did we get hereIt's worth reviewing how this code came to be before tearing down this "Chesterton's fence". Originally we didn't compute Lines 711 to 722 in ba3e39f Back then, for In b075e2c we added the computation for In 6f3a3e0 we decide that it was fine for Lines 682 to 691 in 5afc82e With this change, the whole existence of the |
For the case of
COMP, iftype_dag[COMP_B(...)].bitSizeexceedsUNBOUNDED_MAX, then the bounded_add and friends functions will already setextraCellsBound[0]andextraCellsBound[1]toUBOUNDED_MAX. Therefore the branch doesn't have any computational effect. It is also not a case worth optimizing for.The case of
DISCONNECTis similar, however possibly only one ofextraCellsBound[0]orextraCellsBound[1]will end up being set toUBOUNDED_MAXinstead of both.This is fine, because these values are just intermediate values for the
*cellsBoundcomputation at the end of the function. There we take the bounded_max of both theextraCellsBound[0]andextraCellsBound[1]functions. So the result is the same whether or not bothextraCellsBoundvalues are maxed out or only one is.