[llvm-dev] Wrong code bug after GVN/PRE?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 20 15:19:47 PST 2017
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.
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:
> 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
> pointers, only pointers they directly touch).
> There's already a bug filed about this.
> You mean
> 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
> 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
> 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) 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
> 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)
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev