[llvm-dev] Wrong code bug after GVN/PRE?

[Daniel Berlin via llvm-dev]

On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén <mikael.holmen at ericsson.com>
wrote:

> Hi,
>
> On 01/13/2017 10:29 PM, Daniel Berlin wrote:
>
>> Yeah, there's a lot of things this could be.
>>
>> On the memdep side:
>> Note that memdep is not actually properly updated in all cases by most
>> passes that claim to not invalidate it (they don't invalidate dependent
>> pointers, only pointers they directly touch).
>>
>> There's already a bug filed about this.
>>
>
> You mean
>  https://llvm.org/bugs/show_bug.cgi?id=27740
> ?

Among others.


>
>
> So far we've only seen
>> missed-opt, not wrong code from this.
>> But it should be possible to generate wrong code bugs with it (if you
>> place the load/store in a place that invalidates the cached dependent
>> result) , so i wonder if this is one.
>>
>
> Any idea what to do about it?
>
> It depends on where the real bug is.


You filed a reproducer that does not require running the other passes
first, which means it's either just a bug in PRE, or a bug in memdep.

If i was a betting man, i'd bet on PRE and it's inter-iteration pre
attempts.
Staring at this case for a second, my money is on the following happening.

1. PRE starts by asking if the value of step[i] where i == 0 is fully
available in all preds
2. PHITransaddr get it as part of memdep, and inside of those preds (which
are in loop 1, not loop2), using it's magical powers, gives an answer about
step[i] (note, not step[0]) instead.  This answer may even be valid in the
loop.  The problem  may even be related to the fact that the loops both
iterate the same way (so it thinks step[i] is valid in both, even though
the i's are different).
3. The answer is not valid outside of the loop, but it now thinks the value
is fully available
4. It performs insertions and gives you the wrong answer.

If i disable all of phitransaddr's fun magic, your testcase starts working.

I'll be honest, i don't have the energy ATM to track down what fun safety
condition it's missing here.
I'd actually rather disable the code (which is a mess) and focus on
improving looploadelimination.
Maybe someone else wants to take a look at it.

(I'll add all this to the bug)

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/551f2f7f/attachment.html>