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