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>