On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
> > That is EH, then there are calls that might not return because they leave
> > in some other way (e.g. longjmp), or might loop forever, might exit, might
> > abort, trap etc.
> Generally speaking, calls which do not return should not now be a problem...
> as long as they do not transfer control to somewhere else in the current
> function.
I thought all of those cases are very relevant to PR104530.
If we have:
_1 = ptr_2(D) == 0;
// unrelated code in the same bb
_3 = *ptr_2(D);
then in light of PR104288, we can optimize ptr_2(D) == 0 into true only if
there are no calls inside of "// unrelated code in the same bb"
or if all calls in "// unrelated code in the same bb" are guaranteed to
return exactly once. Because, if there is a call in there which could
exit (that is the PR104288 testcase), or abort, or trap, or loop forever,
or throw externally, or longjmp or in any other non-UB way
cause the _1 = ptr_2(D) == 0; stmt to be invoked at runtime but
_3 = *ptr_2(D) not being invoked, then we can't optimize the earlier
comparison because ptr_2(D) could be NULL in a valid program.
While if there are no calls (and no problematic inline asms) and no trapping
insns in between, we can and PR104530 is asking that we continue to optimize
that.
Jakub
