[LLVMdev] The "scope" of passes
ether zhhb
etherzhhb at gmail.com
Sat Apr 17 06:57:41 PDT 2010
hi John,
sorry for reply so late.
On Tue, Apr 13, 2010 at 10:38 PM, John Criswell <criswell at uiuc.edu> wrote:
> Devang Patel wrote:
>
>> On Mon, Apr 12, 2010 at 6:41 PM, ether zhhb <etherzhhb at gmail.com> wrote:
>>
>>
>>
>>> that's because FunctionPass implement the "addLowerLevelRequiredPass"
>>> function, but others not.
>>>
>>> so, is there any special reason that only "addLowerLevelRequiredPass" is
>>> allow?
>>>
>>>
>>>
>>
>> There is no reason to not allow it. It is not done because there was
>> not any use. If you need this then pl. prepare a patch!
>>
>>
>
> Alternatively, if you wrote the BasicBlock analysis pass, you could easily
> modify it to be a FunctionPass.
>
yep, if we just concerning use BB pass in Function pass, we can just change
it into a Function pass. (In fact, i had do something like this before :) )
But the problem is, sometimes, the BB pass PassA use by some Function pass
requires others BB pass for analysis result, so we had to rewrite all the
passes required by PassA to Function pass, so that PassA can get the
analysis :(
>
> Currently, I think this is a better alternative because:
>
> 1) It doesn't require patching LLVM (meaning that your passes can work with
> LLVM 2.7)
2) You will get better reusability of the analysis results. When a higher
> level pass calls a lower level pass (e.g., ModulePass calls FunctionPass),
> the lower level pass is run again, even if it was run previously and did not
> have its analysis results invalidated. If the passes are of the same level
> (e.g., FunctionPass requires FunctionPass), then the PassManager can avoid
> duplicate runs of the analysis pass if its results are not invalidated.
>
yep, this make sense.
>
> -- John T.
>
> -
>> Devang
>>
>>
>
> best regards
--ether
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100417/64cfa4b4/attachment.html>
More information about the llvm-dev
mailing list