Displaying 6 results from an estimated 6 matches for "analyzebasicblock".
2010 Apr 19
2
[LLVMdev] The "scope" of passes
...FunctionPass requests the results of BasicBlockPass, that BasicBlockPass
will be re-run, even if it was run previously and not invalidated.
Plus, you can always write a BasicBlockPass *and* a FunctionPass that
reuse the same code. For example, you could structure your code this way:
classname::analyzeBasicBlock (BasicBlock & BB) {
...
}
BBClassName::runOnBasicBlock (BasicBlock & BB) {
analyzeBasicBlock (BB):
}
FuncClassName::runOnFunction (Function & F) {
for each basic block in F {
analyzeBasicBlock (BB)
}
}
The you either use the BasicBlockPass or FunctionPass depen...
2010 Apr 20
0
[LLVMdev] The "scope" of passes
...will not give significant advantage to
llvm, since the we almost do not need to run passes "out of scope".
>
> Plus, you can always write a BasicBlockPass *and* a FunctionPass that reuse
> the same code. For example, you could structure your code this way:
>
> classname::analyzeBasicBlock (BasicBlock & BB) {
> ...
> }
>
> BBClassName::runOnBasicBlock (BasicBlock & BB) {
> analyzeBasicBlock (BB):
> }
>
> FuncClassName::runOnFunction (Function & F) {
> for each basic block in F {
> analyzeBasicBlock (BB)
> }
> }
>
or
BBC...
2010 Apr 17
0
[LLVMdev] The "scope" of passes
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
2010 Apr 13
2
[LLVMdev] The "scope" of passes
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?
>>
>>
>
>
2010 May 18
0
[LLVMdev] suggestion: add a member in llvm::CodeMetrics
Is it worthwhile to add a
void analyzeInstRange(InstIter begin, InstIter end) {}
which estimate code metrics of any instruction range in a basic block.
Or we are good with analyzeBasicBlock as an upperbound?
thanks
yuanfang
2011 Mar 30
0
[LLVMdev] GSoC: Profile-guided inlining and block positioning
...new optimization pass, which will
perform the following sequence of operations:
1. Determine a maximum cost for the whole inlining process. This can be*S *
1.1*, where *S *is the estimated size of the application (this can be an
estimate of the total number of instructions, the way*
CodeMetrics::analyzeBasicBlock* does it). Multiplying by* 1.1* means that a
code growth of maximum 10% is allowed, which has been shown to be more than
enough. If optimization for size is enabled we could allow a code growth of
only 1%, which still provides most of the benefits.
2. Determine the call sites, and for each on...