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

[Philip Reames via llvm-dev]

If someone can produce an *IR* reproducer which they believe is 
incorrect, I'm happy to take a look at the PRE code.  I will not have 
the time to reproduce this from C or work through the interaction of 
other passes;  I will only look at this if there is a bug with PRE 
specific IR reproducer attached.

Philip


On 01/16/2017 10:14 AM, Daniel Berlin via llvm-dev wrote:
>
>
> On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén 
> <mikael.holmen at ericsson.com <mailto: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
>     <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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170120/38d75e68/attachment.html>