This is an archive of the discontinued LLVM Phabricator instance.

[BasicAA] Fix zext & sext handling
ClosedPublic

Authored by njw45 on Aug 7 2015, 2:12 PM.

Details

Summary

Un-revert of r241981 and fix for PR23626. The 'Or' case of GetLinearExpression delegates to 'Add' if possible, and if not it returns an Opaque value. Unfortunately the Scale and Offsets weren't being set (and so defaulted to 0) - and a scale of zero effectively removes the variable from the GEP instruction. This meant that BasicAA would return MustAliases when it should have been returning PartialAliases (and PR23626 was an example of the GVN pass using an incorrect MustAlias to merge loads from what should have been different pointers).

Diff Detail

Event Timeline

njw45 updated this revision to Diff 31542.Aug 7 2015, 2:12 PM
njw45 retitled this revision from to [BasicAA] Fix zext & sext handling.
njw45 updated this object.
njw45 added a reviewer: hfinkel.
njw45 added a subscriber: llvm-commits.
hfinkel accepted this revision.Aug 15 2015, 2:12 AM
hfinkel edited edge metadata.

A few small comment improvements, but otherwise, LGTM.

lib/Analysis/BasicAliasAnalysis.cpp
170

The formatting would be better here if you broke the line before the ZExt(

205

We should document what NSW/NUW mean (I realize this is somewhat obvious, but even so) and that they should both be set to true before calling this at the top level.

Similarly, ZExtBits, SExtBits, Offset and Scale need to be zero, and we should say that as well.

222

if -> If

229

The comment here says, "and remove the variable", but this seems slightly misleading (I'd assume that means returning a nullptr or Undef). Really, the value will be ignored because the Scale is never changed from zero.

624

The comment should explain what the return value actually means.

This revision is now accepted and ready to land.Aug 15 2015, 2:12 AM
hans added a subscriber: hans.Aug 18 2015, 3:05 PM

Did this get committed? Is this a fix we need for 3.7?

In D11847#227037, @hans wrote:

Did this get committed? Is this a fix we need for 3.7?

From what qcolombet mentioned, this fixes a bug introduced in r221876. That would make it nice to have in 3.7, and I'm fine with it being committed to trunk and making my requested commentary improvements in follow-up. However, this is not purely a bug fix, and furthermore, this fix itself has been committed/reverted before as well. I'm nervous about merging it into the release branch late in the release cycle. It might be best to revert r221876 in the release branch instead. Is there going to be another release candidate at this point before 3.7?

hans added a comment.Aug 18 2015, 3:41 PM
In D11847#227037, @hans wrote:

Did this get committed? Is this a fix we need for 3.7?

From what qcolombet mentioned, this fixes a bug introduced in r221876. That would make it nice to have in 3.7, and I'm fine with it being committed to trunk and making my requested commentary improvements in follow-up. However, this is not purely a bug fix, and furthermore, this fix itself has been committed/reverted before as well. I'm nervous about merging it into the release branch late in the release cycle. It might be best to revert r221876 in the release branch instead. Is there going to be another release candidate at this point before 3.7?

r221876 also doesn't look like a trivial patch. It's hard to follow along with all the reverted reverts here.

From what I understand, PR23626 that's mentioned here was already fixed by reverting something else on 3.7, so maybe we don't need this or reverting r221876?

There have been a number of merges after 3.7-rc2, so there will be an rc3, but I'm hoping that will become the final one.

In D11847#227079, @hans wrote:
In D11847#227037, @hans wrote:

Did this get committed? Is this a fix we need for 3.7?

From what qcolombet mentioned, this fixes a bug introduced in r221876. That would make it nice to have in 3.7, and I'm fine with it being committed to trunk and making my requested commentary improvements in follow-up. However, this is not purely a bug fix, and furthermore, this fix itself has been committed/reverted before as well. I'm nervous about merging it into the release branch late in the release cycle. It might be best to revert r221876 in the release branch instead. Is there going to be another release candidate at this point before 3.7?

r221876 also doesn't look like a trivial patch. It's hard to follow along with all the reverted reverts here.

From what I understand, PR23626 that's mentioned here was already fixed by reverting something else on 3.7, so maybe we don't need this or reverting r221876?

There have been a number of merges after 3.7-rc2, so there will be an rc3, but I'm hoping that will become the final one.

Okay; I'll make sure this gets committed today.

qcolombet closed this revision.Aug 31 2015, 3:40 PM

Committed on Nick’s behalf in r246502.