[llvm-dev] Guidelines for pass initialization?

[Philip Reames via llvm-dev]

Let me rephrase to make sure I understand.  Once we have this settled, 
I'll update the comments in the file to summarize and possibly update 
the docs.

On 08/21/2015 10:27 AM, Owen Anderson wrote:
> The macro versions should be preferred, as they reduce static initializaters.
Makes sense.  But the tradeoff is that they need to be baked into the 
list of known passes so that someone knows to call them?  So, if you 
have a pass which isn't part of LLVM itself, you should prefer 
RegisterPass?  Seems to make sense.  Is there also an implicit 
assumption here that any RegisterPass pass is a leaf in the dependency 
graph?  i.e. you couldn't use this to define your own Analysis?
>
> INITIALIZE_PASS is used for a pass that is a leaf in the dependency graph, whereas INITIALIZE_PASS_BEGIN is used for interior nodes.
Almost all transform passes - with the exception of LoopSimplify and the 
like - do not have passes which require them.  As a result, most 
transform passes are leaves in the dependency graph and should use the 
INITIALIZE_PASS mechanism.  All Analysis passes are expected to have 
consumers, so they are obvious not leaf and should use the 
INITIALIZE_PASS_BEGIN mechanism.  Is that a reasonable summary?
>
> —Owen
>
>> On Aug 21, 2015, at 10:15 AM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Does anyone know what the guidelines are supposed to be for properly initializing a pass?  Looking around, we seem to have three styles of pass registration in use.
>>
>> INITIALIZE_PASS(...)
>>
>> INITIALIZE_PASS_BEGIN(...)
>> INITIALIZE_PASS_DEPENDENCY(...)
>> ...
>> INITIALIZE_PASS_END(...)
>>
>> static RegisterPass<FooPass> X(...);
>> (This is the one encouraged in the docs, but seemingly the least widely used in tree?)
>>
>> As far as I can tell, these often appear to work interchangeably. (At least for passes with only "well known" dependencies.)  Can anyone expose a set of guidelines as to when one should use each?
>>
>> Philip
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev