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.
Martin
Richard
