This is an archive of the discontinued LLVM Phabricator instance.

[TBAA] Don't generate invalid TBAA when merging nodes
ClosedPublic

Authored by sanjoy on Nov 14 2016, 1:48 PM.

Details

Summary

Fix a corner case in MDNode::getMostGenericTBAA where we can sometimes
generate invalid TBAA metadata.

Diff Detail

Repository
rL LLVM

Event Timeline

sanjoy updated this revision to Diff 77879.Nov 14 2016, 1:48 PM
sanjoy retitled this revision from to [TBAA] Don't generate invalid TBAA when merging nodes.
sanjoy updated this object.
sanjoy added a subscriber: llvm-commits.
manmanren edited edge metadata.Nov 15 2016, 4:30 PM

Cheers,

Manman

lib/Analysis/TypeBasedAliasAnalysis.cpp
462 ↗(On Diff #77879)

When the only common base is the root node, is it illegal to generate a tag based on the root?

unittests/Analysis/TBAATest.cpp
75 ↗(On Diff #77879)

Why are we testing the old scalar TBAA here with createTBAANode?

sanjoy added inline comments.Nov 15 2016, 4:49 PM
lib/Analysis/TypeBasedAliasAnalysis.cpp
462 ↗(On Diff #77879)

The comment at the top of the file states:

The second field is the access type node, it
// must be a scalar type node.
unittests/Analysis/TBAATest.cpp
75 ↗(On Diff #77879)

The OldTBAATest name is misleading here, I'll change it to be more generic. However, the only thing we've deprecated and removed support is the using scalar tbaa *tags*. So far I don't see anything in the TBAA implementation that indicates we don't support scalar TBAA *nodes*. For instance, see line 247:

// Fast path for a scalar type node and a struct type node with a single
// field.
if (Node->getNumOperands() <= 3) {
  uint64_t Cur = Node->getNumOperands() == 2
                     ? 0
                     : mdconst::extract<ConstantInt>(Node->getOperand(2))
                           ->getZExtValue();
  Offset -= Cur;
  MDNode *P = dyn_cast_or_null<MDNode>(Node->getOperand(1));
  if (!P)
    return TBAAStructTypeNode();
  return TBAAStructTypeNode(P);
}

Even if removing scalar TBAA nodes completely is going to ultimately be a better final state (I think it will be), the amount of work is non-trivial I'd rather not fold in all of that work in this cleanup work I'm currently doing.

sanjoy updated this revision to Diff 78101.Nov 15 2016, 4:51 PM
sanjoy edited edge metadata.
  • address review comments
sanjoy updated this revision to Diff 78102.Nov 15 2016, 4:52 PM
  • Fix test name
manmanren added inline comments.Nov 17 2016, 3:17 PM
lib/Analysis/TypeBasedAliasAnalysis.cpp
462 ↗(On Diff #77879)

I see. I was wondering if it caused any compilation failure or miscompile.

unittests/Analysis/TBAATest.cpp
75 ↗(On Diff #77879)

We have createTBAAScalarTypeNode and it is used by clang currently to generate a scalar type node.
createTBAANode was used by clang with the old TBAA scalar system.

sanjoy added inline comments.Nov 17 2016, 5:08 PM
lib/Analysis/TypeBasedAliasAnalysis.cpp
462 ↗(On Diff #77879)

I don't think today it would lead to an actual miscompile. It just breaks the spec and hence the verifier.

unittests/Analysis/TBAATest.cpp
75 ↗(On Diff #77879)

Yes, but there are out of tree non-clang users who use createTBAANode today.

I agree that it would be nice to get rid of scalar TBAA completely, but I don't want to change too much at once. In particular, I think once D26438 is checked in (I'm also waiting for you to take a look at that one, btw :) ) it will likely break out of tree users since today it is too easy to generate slightly malformed TBAA and not realize it[0]. I want to check in D26438 first, let that bake in for some time, and then ditch scalar tbaa once out of tree users have recovered from D26438.

[0]: For instance, we were generating bad TBAA internally for a while, and things actually worked okay till one day they didn't.

manmanren accepted this revision.Nov 18 2016, 12:29 PM
manmanren edited edge metadata.

In particular, I think once D26438 is checked in (I'm also waiting for you to take a look at that one, btw :) )

I will take a look at that soon :)

Manman

This revision is now accepted and ready to land.Nov 18 2016, 12:29 PM
This revision was automatically updated to reflect the committed changes.