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