This is an archive of the discontinued LLVM Phabricator instance.

Small refactor on VectorizerHint for deduplication
ClosedPublic

Authored by rengolin on Aug 14 2014, 1:47 PM.

Details

Summary

Previously, the hint mechanism relied on clean up passes to remove redundant
metadata, which still showed up if running opt at low levels of optimization.
That also has shown that multiple nodes of the same type, but with different
values could still coexist, even if temporary, and cause confusion if the
next pass got the wrong value.

This patch makes sure that, if metadata already exists in a loop, the hint
mechanism will never append a new node, but always replace the existing one.
It also enhances the algorithm to cope with more metadata types in the future
by just adding a new type, not a lot of code.

Fixes PR20655.

Diff Detail

Event Timeline

rengolin updated this revision to Diff 12524.Aug 14 2014, 1:47 PM
rengolin retitled this revision from to Small refactor on VectorizerHint for deduplication.
rengolin updated this object.
rengolin edited the test plan for this revision. (Show Details)
rengolin added reviewers: nadav, aschwaighofer.
rengolin set the repository for this revision to rL LLVM.
rengolin added a project: deleted.
rengolin added subscribers: Unknown Object (MLST), ArchDRobison.

Minor editorial comments. I'm not an LLVM expert.

lib/Transforms/Vectorize/LoopVectorize.cpp
1117

Should the cast be dyn_cast?

1137

Is it safe to assume that the operands are all MDNode and not other kinds of values? If not, consider not casting here, and instead pass a Value* to "matchesHintMetadataName" and do the check for MDNode-ness there.

1139

The if/continue/else seems a bit wordy. It would be shorter to write:

if (!matchesHintMetadataNameNode, HintTypes))

Vals.push_back(Node);
1180–1181

"this" should be "these".

Thanks for the review, Arch.

Sending a new patch with the updates.

cheers,
--renato

lib/Transforms/Vectorize/LoopVectorize.cpp
1117

Yes, thanks!

1137

It should, since this is the only class touching that part. But I agree it's not the safest way to go. One needs to revise the metadata handling in the loop vectorizer as a whole, I believe. Maybe not for this patch, though.

1139

That's the result of a different piece of code. Updated, thanks!

1180–1181

Thanks!

rengolin updated this revision to Diff 12588.Aug 17 2014, 5:38 AM

Updating from Arch's comments.

Hi Renato,

This LGTM. I have only minor stylistic comments:

I think this would reads easier if we refer to Hint and Hints instead of HintType(s).

We concatenate and split "llvm.loop" and "vectorize.foo". I think it would simplify the code if the Hints refer to the full string?

Can we centralize the logic if we move the validation logic into a member function "validate" that switches on a hint kind? Validation and the hint are intrinsically connected.

struct Hint {
 enum Kind {
  kUnroll, ...} HintKind;

  Hint(Kind K, StringRef Name...) {}

  bool validate() {
   switch(HintKind) { 
      case kUnroll:
   }
 }
};

Thanks for fixing this.

Hi Arnold,

Thanks for your review. Replies inline.

I think this would reads easier if we refer to Hint and Hints instead of HintType(s).

Fair enough, I can change that.

We concatenate and split "llvm.loop" and "vectorize.foo". I think it would simplify the code if the Hints refer to the full string?

We do that to validate and only warn if it's an invalid "llvm.loop." metadata, so we don't even scan the others (like tbaa, etc). Adding it to the name will simplify the pattern match on the hint but would make warning a bit harder. I will move the matching on the prefix to the parseHint() to make it a bit more isolated, and easier to change in the future.

Can we centralize the logic if we move the validation logic into a member function "validate" that switches on a hint kind? Validation and the hint are intrinsically connected.

So, I though about using an enum to validate, but that meant we'd have to construct a new Hint from a string and assign a kind just to check if it's a valid hint at all, and then add InvalidHint objects and making sure none of the objects are duplicated. It got a bit complex...

Since we don't use static initializers, and this is only built once, and the constructor is statically set on the right validation lambda for each string, I thought it'd be at least safe. I agree it's not pretty.

I'll give it a few more tries...

cheers,
--renato

Right, found an easy way to work around the validation problem. Committed in r215994.

Thanks!
--renato

rengolin accepted this revision.Sep 7 2014, 11:29 AM
rengolin added a reviewer: rengolin.

Accepting to close

This revision is now accepted and ready to land.Sep 7 2014, 11:29 AM
rengolin closed this revision.Sep 7 2014, 11:29 AM