NoQ added a comment.
> I am not sure about assuming operator bool being correct. I think we first
> could think about other tricks to limit the tracking (see my idea above) and
> if we fail I would only add such rules as a last resort.
I think this depends greatly on the stack frame layout. I seem to be perfectly
fine with not tracking the value within `foo()` in
if (foo()) {
...
}
whenever `foo()` returns a `bool`. Simply because "why else would you add a
check if it always returns the same value?".
However, this heuristic breaks when the same code appears in an inlined stack
frame. Because given the context, we need to prove that this check makes sense
*in this context*.
I strongly suspect that all of the heuristics that you're talking about depend
significantly on the surrounding call stacks. Like, i suspect it so strongly
that i'm ready to admit that i've no idea what we're doing anymore, and it
makes sense to take a pen and a sheet of paper and try to write down the
tracking rules, and then come up with an easily editable and extensible
architecture for tweaking those rules as we discover more and more of them.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62883/new/
https://reviews.llvm.org/D62883
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
