Take operand constness into account in CFG construction. #2238
Conversation
When computing the CFG data access information we would previously assume that any operator use would both read and write its operands, e.g., we would assume that an equality check could write its operands. Due to how we resolve operators of non-const operands this does reflect what we see in many ASTs, but does not take into account when we actually use an operand as const. This patch adds handling of operators so that we can avoid recording writes when the operand is used as const.
CodSpeed Performance ReportMerging #2238 will not alter performanceComparing Summary
|
| else if ( auto* operator_ = node->tryAs<expression::ResolvedOperator>(); | ||
| operator_ && isConstOperand(*operator_, *name) ) |
There was a problem hiding this comment.
For non-const uses we still fall through to the else branch which also sets the node keep.
Ideally we'd handle all operators here, always set read and write for non-const uses. We still would need extra handling for member-like operators which could have side effects (definitely MemberCall, possibly Member and TryMember).
There was a problem hiding this comment.
We should be able to look at the operator's signature: all the method-like operators have a self with a Kind that's either In or InOut. And generally, the signatures are good to look at for all operands I think: In is read-only, InOut means operator can modify the operand.
I looked into this since I saw a
write: [i]in the CFG in #2236. This fixes a small issue, but there is definitely more we could do here.