[llvm-commits] [llvm] r116905 - in /llvm/trunk: docs/WritingAnLLVMPass.html include/llvm/Analysis/RegionPass.h include/llvm/Pass.h include/llvm/PassManagers.h lib/Analysis/CMakeLists.txt lib/Analysis/RegionPass.cpp lib/VMCore/PassManager.cpp tools/opt/opt.cpp

Duncan Sands baldrick at free.fr
Tue Oct 19 23:47:57 PDT 2010


Hi Tobias,

> +the<tt>RGPassManager</tt>  interface. You may overload three virtual methods of
> +<tt>RegionPass</tt>  to implementing your own region pass is usually. All these

the sentence starting with "You may overload..." doesn't seem to make sense.

> +methods should return true if they modified the program, or false if they didn not.

didn not -> did not

> +<p>The<tt>doInitialization</tt>  method is designed to do simple initialization
> +type of stuff that does not depend on the functions being processed.  The

No need for "type of stuff", can just be "simple initialization that does not..."

> +<tt>doInitialization</tt>  method call is not scheduled to overlap with any
> +other pass executions (thus it should be very fast). RPPassManager

I'm not sure what "not scheduled to overlap with any other pass executions
(thus it should be very fast)" is trying to say.  What is "overlap" about?
Is "thus it should be very fast" telling people that they need to make sure
that their "doInitialization" method is fast?  And why does the conclusion "it
should be very fast" follow from "not scheduled to overlap with"...  Confused.


> +be returned if the region is modified.<tt>RGPassManager</tt>  interface
> +should be used to update region tree.</p>

<tt>RGPassManager</tt> -> The <tt>RGPassManager</tt>


> +// This file defines the RegionPass class. All region based analysis,
> +// optimization and transformation passes are derived from RegionPass.
> +// This class is implemented following the some ideas of the LoopPass.h class.

the some ideas of -> (?) the same ideas as
Or maybe: following the some ideas of -> along the same lines as

> +// This file implements RegionPass and RGPassManager. All region optimization
> +// and transformation passes are derived from RegionPass. RGPassManager is
> +// responsible for managing RegionPasses.
> +// most of these codes are COPY from LoopPass.cpp

I think you can remove the last line (most of these codes...).

> +// Check if this pass is suitable for the current RGPassManager, if
> +// available. This pass P is not suitable for a RGPassManager if P
> +// is not preserving higher level analysis info used by other
> +// RGPassManager passes. In such case, pop RGPassManager from the
> +// stack. This will force assignPassManager() to create new
> +// LPPassManger as expected.

LPPassManger -> (?) RGPassManager
Otherwise, LPPassManger -> LPPassManager

> +  // If this pass is destroying high level information that is used
> +  // by other passes that are managed by LPM then do not insert
> +  // this pass in current LPM. Use new RGPassManager.

Are these references to LPM correct, or should they be to RGPM?

Ciao,

Duncan.



More information about the llvm-commits mailing list