[LLVMdev] Heads up: Pass Manager changes will be starting shortly

[Chris Lattner]

On Sep 14, 2013, at 3:46 PM, Chandler Carruth <chandlerc at google.com> wrote:

> I just wanted to give everyone a head up. I'm starting work on the pass manager based on numerous list discussions and some IRC discussions.

Great!  Aside from mailing list discussions, do you have a whitepaper that describes the end-result that you're shooting for?  It doesn't need to be overly formal, but something along the lines of http://nondot.org/sabre/LLVMNotes/ would be useful.

> The first steps will be marking the existing code as "legacy" and clearing a path to build new facilities here. From there I'll start building the new facilities without enabling them.
> 
> Some explicit legacy support goals:
> 
> 1) I'm going to build a bridge so that an existing Pass can be inserted into the new pass manager with some adaptors and everything will just work. This may require touching the code that sets up the pass manager, but not the code that defines a pass. This will work even once the new pass manager bits are enabled if at all possible.
> 
> 2) If you have code that includes the current PassManager headers, nothing should break right away, but when the new manager infrastructure is enabled, I'll likely remove the old PassManager headers, breaking this code. My goal is to only break code that directly interacts with the management layer.
> 
> 3) I'm going to play namespace games so that we don't end up with PassManagerV2 and other silly names. The legacy headers will paper over this to keep legacy code compiling without change.

Sounds great to me, incremental is good.  I think it's perfectly fine to do something like:

class PassManagerV2 { … }

#ifdef NEW_STUFF
#define PassManager PassManagerV2
#else
class PassManager { … }
#endif

or something.  It's horribly gross, but as long as you're committed to finishing the work, it can be useful for staging the change.

-Chris