Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] idf_iterator and MachineFunctions"
2007 Mar 18
0
[LLVMdev] idf_iterator and MachineFunctions
On 2007-03-18, at 03:22, Lang Hames wrote:
> Is there a recommended way to find the final block (the one with
> successors={}) in a machine function?
This isn't a property of the CFG in the general case. However, the
UnifyFunctionExitNodes transformation/analysis provides it. From
getAnalysis<UnifyFunctionExitNodes>().getReturnBlock(), you can visit
the basic block
2007 Mar 19
0
[LLVMdev] idf_iterator and MachineFunctions
On Sun, 18 Mar 2007, Lang Hames wrote:
> I need to do an inverse-depth-first iteration over the basic blocks in
> a machine function (i.e. starting from the last block and following
> predecessor edges) for a liveness analysis I'm writing.
As Gordon mentioned, there isn't a trivial way to do this, as there isn't
a single exit node in the MBB CFG.
> idf_iterator seems
2008 Jan 23
1
[LLVMdev] Walking all the predecessors for a basic block
Hi,
Well, yes i did try your suggestion but i keep on running into a
compilation problem.
The error is:
llvm[0]: Compiling Hello.cpp for Release build (PIC)
/home/saraswat/llvm/llvm-2.1/include/llvm/ADT/GraphTraits.h: In
instantiation of
`llvm::GraphTraits<llvm::ilist_iterator<llvm::BasicBlock> >':
Hello.cpp:59: instantiated from here
2008 Jan 22
0
[LLVMdev] Walking all the predecessors for a basic block
Hi Pabhat,
Have you checked out DepthFirstIterator? (include/llvm/ADT/
DepthFirstIterator.h). It provides an iterator abstraction to perform
a forward/reverse DFS traversal of a graph.
Many of the LLVM datatypes that represent graphs have a template
specialization of the GraphTraits<> class which allows separate
algorithms to treat them as graphs, walk them, etc. (Both BasicBlock
2008 Jan 22
3
[LLVMdev] Walking all the predecessors for a basic block
Hi all,
Is there a way to walk through ALL the predecessors of a basic block
in a CFG. I tried to iterate over the preds using this method
for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++I) {
BasicBlock *PredBB = *PI;
}
but this only gives the immediate predecessors for a basic block.
For example, in this sample control flow graph.
entry -> bb1 -> bb2 -> bb4
2010 Mar 31
0
[LLVMdev] CFG entry and exit blocks
Dear Trevor,
I'm too lazy to convert your .dot file into a graph file, but I'll make
some comments anyway.
:)
First, LLVM does not guarantee that a function has a single exit block.
Multiple basic blocks can have a return instruction as their terminator
instruction. There is a pass (Unify Function Exit nodes i.e.,
-mergereturn <http://llvm.org/docs/Passes.html#mergereturn>)
2010 Mar 31
2
[LLVMdev] CFG entry and exit blocks
Hi,
I'm confused about the entry and exit blocks of an LLVM CFG. I
understand that every CFG has one and only one entry block, and this
is confirmed by the existence of the getEntryBlock function in the
Function class.
But what about exit (a.k.a. return) blocks? At first I assumed that
LLVM CFGs have one and only one exit block, too, but the following
code is a counter-example:
2010 Mar 31
2
[LLVMdev] CFG entry and exit blocks
On Mar 30, 2010, at 7:51 PM, John Criswell wrote:
> I'm too lazy to convert your .dot file into a graph file
What format should I have posted? (I'm not sure what you mean by
"graph file".) I had thought that .dot was the preferred format here,
since that's what LLVM generates (e.g., "opt -dot-cfg ...").
> First, LLVM does not guarantee that a function
2006 May 03
1
[LLVMdev] Patch for transform dependencies
Hi,
A number of transforms are actually independent, so here's a partial fix. I
updated the
dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect,
LowerAllocations, UnifyFunctionExitNodes.
The patch has been tested, but not extensively. PassManager doesn't
complain, and
the result of a test pass that requires all these (except for
LowerAllocations) together
works
2006 May 03
2
[LLVMdev] Conflicting passes?
Hi all,
Why are these two passes conflicting: UnifyFunctionExitNodes and LowerSwitch?
AU.addRequired(LowerSwitchID) works, so does AU.addRequired<unifyFunctionExitNodes>(),
but the two together don't...
opt: PassManagerT.h:387: void llvm::PassManagerT<Trait>::markPassUsed(const llvm::PassInfo*, llvm::Pass*) [with Trait = llvm::MTraits]: Assertion `getAnalysisOrNullUp(P)
2010 Jul 22
3
[LLVMdev] Controlling the order of a FunctionPass
On Jul 22, 2010, at 2:05 PM, John Criswell wrote:
> If you write your pass as a ModulePass, then you can iterate over the
> functions in any order that you want.
I had considered that, but my FunctionPass depends on other passes
processing the functions first:
void MyPass::getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<UnifyFunctionExitNodes>();
2006 Oct 08
1
[LLVMdev] modulepass requiring a functionpass
I have a ModulePass, which we'll call MP, that generates a dependency
graph for an entire program. I want MP to require the
UnifyFunctionExitNodes pass, which is a FunctionPass. Since its not
possible to make a ModulePass depend on a FunctionPass, is my only
choice to make MP a FunctionPass in which the runOnFunction() routine
does nothing, and the doFinalization routine does all the
2010 Jul 23
0
[LLVMdev] Controlling the order of a FunctionPass
Trevor Harmon wrote:
> On Jul 22, 2010, at 2:05 PM, John Criswell wrote:
>
>
>> If you write your pass as a ModulePass, then you can iterate over the
>> functions in any order that you want.
>>
>
> I had considered that, but my FunctionPass depends on other passes
> processing the functions first:
>
Two things to consider:
1) The PassManager
2010 Jul 24
2
[LLVMdev] Controlling the order of a FunctionPass
John Criswell wrote:
> Trevor Harmon wrote:
>> On Jul 22, 2010, at 2:05 PM, John Criswell wrote:
>>
>>
>>> If you write your pass as a ModulePass, then you can iterate over the
>>> functions in any order that you want.
>>>
>>
>> I had considered that, but my FunctionPass depends on other passes
>> processing the functions first:
2002 Nov 29
2
[LLVMdev] Fake Exit node
Is there a facility with which we may automagically create a "fake" exit
node, one that is the target of all BasicBlocks ending in return. This
would be very helpful to IP dataflow analysis...
Dave
2019 Mar 24
3
call an existing IPO pass
Hi,
I found an existing pass "CalledValuePropagation" that can solve the
problem I raised a few days ago regarding the "callees" metadata (
https://groups.google.com/forum/#!topic/llvm-dev/yjtZVMH_aC4). Now I have
difficulty in calling this pass in my own pass.
In my own pass, I called
"getAnalysis<CalledValuePropagationPass>()"
and in the
2004 Nov 10
3
[LLVMdev] All SingleSource and MultiSource tests failed at FreeBSD
>> All SingleSource and MultiSource tests failed in last run of FreeBSD
>> nighttester (and in previous).
>> Mostly with error:
>
> This looks like your crtend.a file did not get built correctly. Try doing
> make clean/make install in llvm/runtime/ again.
>
gmake clean in llvm/runtime/ remove all build tree of nighttest starting
with llvm/runtime/../..
And then i
2010 Aug 30
1
[LLVMdev] What may I assume about MachineFunctions.
Upon writing my register allocation algorithm, I am concerned that a load
may be skipped due to a branch.
For instance consider the psudocode
int x = 1
...
if( false )
load x
y = 3*x
else
y = 4*x
...
The load happens in the false block because this is when the variable is
first seen. The load is not preformed in the else block because the register
allocator may see it loaded already.
Do
2010 Jul 20
1
[LLVMdev] Rendering MachineFunctions as HTML.
Hi All,
I've developed a pass to render machine functions as HTML pages with some
accompanying information about liveness and register pressure.
Current features:
Renders machine functions, optionally displaying estimated register pressure
for selected register classes, and liveness for selected intervals.
The following command line options can be used to enable and customise the
2010 Mar 31
0
[LLVMdev] CFG entry and exit blocks
On Wed, Mar 31, 2010 at 2:59 PM, Trevor Harmon <trevor.w.harmon at nasa.gov> wrote:
> I'm wondering what would cause a CFG not to have a return block. The
> comments in UnifyFunctionExitNodes.cpp say: "If there are no return
> stmts in the Function, a null pointer is returned." But this doesn't
> make sense; even an empty void function has a return block with a