On Tue, 18 Nov 2014, Jeff Law wrote:

> On 11/18/14 09:57, Tom de Vries wrote:
> > Richard,
> > 
> > this (trunk) patch fixes PR62167.
> > 
> > The patch fixes a problem that triggers with the test-case on the 4.8
> > branch, when tail-merge makes a dead type-unsafe load alive.
> > 
> > I'm not able to reproduce this bug on 4.9 and trunk with the same
> > test-case. On those branches, the tail-merge already does not happen.
> > 
> > The reason for the difference is as follows: With 4.8 the two phi
> > arguments of the phi in the tail block are value-numbered identically:
> > ...
> > SCC consists of: p_14
> > Value numbering p_14 stmt = p_14 = MEM[(struct head *)_13].first;
> > Setting value number of p_14 to p_14 (changed)
> > 
> > SCC consists of: p_15
> > Value numbering p_15 stmt = p_15 = _13->next;
> > Setting value number of p_15 to p_14 (changed)
> > ...
> > 
> > With 4.9 (and trunk), that's not the case:
> > ...
> > SCC consists of: p_14
> > Value numbering p_14 stmt = p_14 = MEM[(struct head *)&heads][k.1_9].first;
> > Setting value number of p_14 to p_14 (changed)
> > 
> > SCC consists of: p_15
> > Value numbering p_15 stmt = p_15 = _13->next;
> > Setting value number of p_15 to p_15 (changed)
> > ...
> > 
> > I'm not sure the bug triggers on trunk and 4.9, but I see no reason why
> > it could not trigger, so I'd prefer to apply the patch to 4.9 and trunk
> > as well.
> > 
> > The patch introduces an xfail for pr51879-12.c. I can follow up with a
> > patch to improve upon that, but I think that's better limited to trunk
> > only.
> > 
> > Bootstrapped and reg-tested on x86_64/trunk.
> So instead of simply disabling for anything with virtual operands, shouldn't
> instead we be comparing the virtual operands and alias information?  Seems to
> me that if we did that properly, this would "just work".  Right?

But that would simply use operand_equal_p () ....

Richard.

Reply via email to