On 1/19/22 09:22, Richard Sandiford wrote:
Martin Sebor <mse...@gmail.com> writes:
On 1/19/22 03:09, Richard Sandiford wrote:
Richard Biener <richard.guent...@gmail.com> writes:
On Tue, Jan 18, 2022 at 2:40 PM Richard Sandiford via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR<svuint64_t[2]>(D.10779) = .MASK_LOAD_LANES (addr_5(D),
64B, _2);
_7 = D.10779.__val[0];
However, the tracking of m_clobbers only looked at gassigns,
so it missed that the clobber on the first line was overwritten
by the call on the second line.
Just as a note another possible def can come via asm() outputs
and clobbers. There would have been walk_stmt_load_store_ops
to track all those down (not sure if the function is a good fit here).
Hmm. Looking at what the pass is doing in more detail, I'm not sure
this approach to handling m_clobbers is safe. The pass walks the
blocks in sequence (rather than using a dom walk, say):
FOR_EACH_BB_FN (bb, fun)
check_block (bb);
so it could see the clobber after a later dominating assignment.
Similarly check_call_dangling could see a use that is “protected”
by a later assignment.
check_call_dangling() reports only uses that are dominated by prior
clobbers (determined in use_after_inval_p) so it should not have
this problem.
Yeah, but what I mean is that, if we have:
A dominates B dominates C
A clobbers X
B defines X
C uses X
we could still see them in this order:
A, C, B
The dominance check would then succeed for <A, C> even though B
should invalidate the clobber.
I see. I think you're right, that case of "clobber revival" isn't
handled. I don't know how to trigger it or have a sense of how
often it might come up (the dangling check runs only very early,
before loop unrolling, to try to avoid it as much as possible).
But running the first loop in dominator order instead as you
suggest should be easy enough. Do you happen to have an idea
for a test case to trigger the problem and verify it's fixed?
Martin
Thanks,
Richard
