melver wrote:

All good points and the motivation that we should relax this a bit is clear.

One observation: for the class of aliasing patterns we're discussing (local 
variable passed by non-const pointer/reference to a function), dropping the 
call-based invalidation is semantically near-identical to your proposal in 
practice - and the lazy approach likely has more edge cases than it first 
appears.

The core difficulty is that translateAttrExpr doesn't just expand local 
variables; it also substitutes the implicit this and takes care of operator 
normalization etc. A syntactic comparator on the raw attribute Expr* would need 
to replicate that substitution logic (it'd become a partial re-implementation 
of the existing translation).

If we just drop the heuristics, none of these are new concerns - the existing 
TIL translation is unchanged and already handles all the cases. We simply stop 
calling clearDefinition for call-escaped variables.

Furthermore, one case where the approaches diverge is a direct reassignment (F 
= &other_foo), which VisitBinaryOperator still tracks correctly if we only drop 
call-based invalidation. Lazy/syntactic matching would miss that case, since 
F->mu still compares equal regardless of what F points to now.

My take is that both approaches (lazy vs. just dropping invalidation 
heuristics) fix the false positive and share the same false-negatives for the 
cases we care about. Just dropping the invalidation heuristics avoids 
introducing a new syntactic comparator with all the edge cases above, and just 
deletes code instead of adding (including the bind/bind_front special case, 
which I should have maybe used as a signal that these heuristics don't scale).

Happy to prepare a PR that drops the invalidation heuristics completely. That 
should take care of most of these issues.


https://github.com/llvm/llvm-project/pull/183640
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to