This is an archive of the discontinued LLVM Phabricator instance.

[PM] Port GVN to the new pass manager, wire it up, and teach a couple of tests to run GVN in both modes.
ClosedPublic

Authored by chandlerc on Mar 9 2016, 5:10 PM.

Details

Summary

This is mostly the boring refactoring just like SROA and other complex
transformation passes. There is some trickiness in that GVN's
ValueNumber class requires hand holding to get to compile cleanly. I'm
open to suggestions about a better pattern there, but I tried several
before settling on this. I was trying to balance my desire to sink as
much implementation detail into the source file as possible without
introducing overly many layers of abstraction.

Much like with SROA, the design of this system is made somewhat more
cumbersome by the need to support both pass managers without duplicating
the significant state and logic of the pass. The same compromise is
struck here.

I've also left a FIXME in a doxygen comment as the GVN pass seems to
have pretty woeful documentation within it. I'd like to submit this with
the FIXME and let those more deeply familiar backfill the information
here now that we have a nice place in an interface to put that kind of
documentaiton.

Diff Detail

Repository
rL LLVM

Event Timeline

chandlerc updated this revision to Diff 50217.Mar 9 2016, 5:10 PM
chandlerc retitled this revision from to [PM] Port GVN to the new pass manager, wire it up, and teach a couple of tests to run GVN in both modes..
chandlerc updated this object.
chandlerc added a subscriber: llvm-commits.
dberlin accepted this revision.Mar 10 2016, 10:52 AM
dberlin added a reviewer: dberlin.
dberlin added a subscriber: dberlin.

Thanks so much for doing this.
This looks completely reasonable to me. While, as you say, this could be cleaned up further, and needs to be better documented, i don't think that's your job.
so LGTM

This revision is now accepted and ready to land.Mar 10 2016, 10:52 AM

Thanks so much for doing this.
This looks completely reasonable to me. While, as you say, this could be cleaned up further, and needs to be better documented, i don't think that's your job.
so LGTM

Thanks for the review! Happy to help with any subsequent cleanups if I can, but yea, I'll probably focus on pass manager-y things for now.

This revision was automatically updated to reflect the committed changes.
davidxl added inline comments.
llvm/trunk/lib/Target/NVPTX/NVPTXTargetMachine.cpp
47

I noticed this line -- why is this inclusion needed?

chandlerc added inline comments.Mar 11 2016, 9:56 AM
llvm/trunk/lib/Target/NVPTX/NVPTXTargetMachine.cpp
47

Because NVPTX adds GVN into its target-specific code generation pass pipeline, and so it needs the 'createGVNPass' function. (You should be able to delete this and see the compile fail. At least, that's how I knew to add it.)

davidxl added inline comments.Mar 11 2016, 9:59 AM
llvm/trunk/lib/Target/NVPTX/NVPTXTargetMachine.cpp
47

The question is why Scalar .h does not include GVN.h?

chandlerc added inline comments.Mar 11 2016, 10:34 AM
llvm/trunk/lib/Target/NVPTX/NVPTXTargetMachine.cpp
47

Historically, LLVM used monolithic headers and functions that returned opaque types for passes.

A large chunk of the new pass manager design moves us towards "normal" patterns. There is a header, with a type, and maybe some helper functions. It allows much more fine grained headers so folks only pull in what they need. And with new-style passes it allows passes to be used outside the context of a pass manager if desirable (for unit testing for example).

If Scalar.h included GVN.h, then it would pull in a pretty large pile of code that doesn't make sense for everyone to pull in.

If Scalar.h continued to own the createGVNPass function, it would break proper modularity, as the constructs being defined in GVN.cpp would be declared in different and fairly distant places.

ok, Scalar.h will eventually be deprecated then.

David