Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] Patch for llvm::DepthFirstIterator.h and llvm::PostOrderIterator.h"
2009 Jun 27
0
[LLVMdev] Patch for llvm::DepthFirstIterator.h and llvm::PostOrderIterator.h
Hi Olaf,
This patch looks good to me. I just have a few minor comments:
> + inline df_iterator() { CurrentTopNode = 0; /* End is when stack
is empty */ }
Should the comment here be updated to say that the End
is reached when the stack is empty and when CurrentTopNode
is null?
> + inline void toNext()
> + {
LLVM style puts the open brace on the same line as the function name.
2009 Jun 15
3
[LLVMdev] Some df_iterator and po_iterator issues
Hi @llvm,
below is a copy of a message I sent to clang a hour before. I guess it's
more appropriate here.
--snip--
While trying to eleminate as much std::tr1::function as possible I
stumbled over a design flaw in llvm::df_iterator.
Consider the following code:
void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn)
{
if (S)
{
fn(S);
for
2009 Jun 29
2
[LLVMdev] [cfe-dev] Patch for llvm::DepthFirstIterator.h and llvm::PostOrderIterator.h
Hi,
I've done all the minor changes you recommended and have attached a new
patch including both files again (even if po_iterator didn't change).
However:
Dan Gohman schrieb:
> The plural of "child" is "children"; please rename this function
> accordingly.
Is "childs" just sloppy, is it american english or is it just a
misconception of foreigners
2009 Jul 07
0
[LLVMdev] Some df_iterator and po_iterator issues
On Jun 15, 2009, at 4:33 AM, Olaf Krzikalla wrote:
> While trying to eleminate as much std::tr1::function as possible I
> stumbled over a design flaw in llvm::df_iterator.
Ok.
> However if fn replaces childrens of a just processed statement
> (which happens a lot), the iteration may crash. Looking at
> df_iterator reveals the reason: the first child of a particular
>
2002 Nov 08
1
[LLVMdev] Iterating on the DSGraph... (fwd)
I use the following code to do the depth first search on the DSGraph. And
I always got this error message. Couldn't figure out what's wrong. Could
you please let me know? Besides, I really have no idea about what those
functions do. Is there any documentation about DSGraph functions besides
the pool allocation paper?
Thanks,
xiaodong
Code:
for( df_iterator<DSNode*> I =
2009 Jul 10
2
[LLVMdev] Some df_iterator and po_iterator issues
Chris,
attached you will find a patch implementing the approach I've posted
yesterday. I don't want the topic fall by the wayside*.
*Note that this patch here contains the df_iterator changes only, some
(IMHO non-critical but needed) po_iterator changes are still in the
pipeline and posted by me in another thread. I hope, the current
approach fits all needs.
Chris Lattner schrieb:
2002 Nov 10
3
[LLVMdev] DSGraph questions
1. What is the difference between DSNodeHandle and DSNode? What do the
functions getLink() and getSize() do?
2. In the previous email, you mentioned that we can use
DSNode::getPointerSize() to get the number of links, But I checked the
doxygen documentation, there is no such member for DSNode.
3. Previously I use the following code:
for( df_iterator<DSNode*> I = df_begin(pnode),
2002 Nov 08
2
[LLVMdev] Re: LLVMdev digest, Vol 1 #44 - 2 msgs
llvm,
What is the best way to implement a traversal of the DS graph, starting at
a scalar and processing all nodes to which the scalar allows access?
Currently the links vector is not public and there is no apparent way to
bound the getLink call (ie a getNumLinks call)....
Dave
2002 Nov 11
1
[LLVMdev] DSGraph questions
Dear Prof. Adve,
I recently checked out the llvm using
cvs update
command under the llvm directory. But when I went to see the DSNode.h,
there is no getPointerSize function. I checked the doxygen tree, it's
there. So that means I didn't update my cvs tree correctly. Could you let
me know how to update my CVS tree? Or there is a problem at somewhere
else?
Thanks,
xiaodong
On Sun, 10 Nov
2002 Nov 18
0
[LLVMdev] Fixed DSGraph iteration, depth first search, etc...
The following now works for me:
const DSNode *N1 = ...;
df_iterator<const DSNode*> X1 = df_begin(N1), XE1 = df_end(N1);
DSNode *N2 = ...;
df_iterator<DSNode*> X2 = df_begin(N2), XE2 = df_end(N2);
You need the following #includes:
#include "Support/DepthFirstIterator.h"
#include "llvm/Analysis/DSGraphTraits.h"
You need this patch:
2009 Sep 06
2
[LLVMdev] Graphviz and LLVM-TV
On 2009-09-06 17:30, Ioannis Nousias wrote:
> I've tried to write a DFGPrinter based on the CFGPrinter, as you
> suggested, but encountered problems.
>
> The GraphWriter expects
> GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is
> implemented in CFG.h, a function is a graph of basic blocks. A
> GraphTraits<Function*> inherits from
2009 Mar 12
4
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Hi John,
It looks pretty good. Thanks for working on this. Some comments:
1. Some of the functions that you introduced, e.g. stringifyCSRegSet
probably ought to be "static" and ifdef'ed out when NDEBUG is defined.
2. + // DEBUG
+ if (! MBB->empty() && ! CSRUsed[MBB].intersects(restore)) {
+ MachineInstr* MI = BeforeI;
+ DOUT <<
2002 Nov 08
0
[LLVMdev] Iterating on the DSGraph...
> What is the best way to implement a traversal of the DS graph, starting at
> a scalar and processing all nodes to which the scalar allows access?
> Currently the links vector is not public and there is no apparent way to
> bound the getLink call (ie a getNumLinks call)....
Warning, untested code follows, but you should get the idea:
#include
2009 Sep 06
0
[LLVMdev] Graphviz and LLVM-TV
Edwin,
thank you for your effort, but I'm not sure I understand.
Are you describing a graph traversal problem? Is the data model stored
in a predecessor/successor fashion, which requires you to 'walk' the
graph in order to visit all nodes? (and what happens when you have
disjointed DFGs?).
inline comments follow...
Török Edwin wrote:
> On 2009-09-06 17:30, Ioannis Nousias
2009 Sep 06
3
[LLVMdev] Graphviz and LLVM-TV
On 2009-09-06 19:57, Ioannis Nousias wrote:
> Edwin,
>
> thank you for your effort, but I'm not sure I understand.
> Are you describing a graph traversal problem? Is the data model stored
> in a predecessor/successor fashion, which requires you to 'walk' the
> graph in order to visit all nodes? (and what happens when you have
> disjointed DFGs?).
Sorry for the
2009 Sep 06
0
[LLVMdev] Graphviz and LLVM-TV
I've tried to write a DFGPrinter based on the CFGPrinter, as you
suggested, but encountered problems.
The GraphWriter expects
GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is
implemented in CFG.h, a function is a graph of basic blocks. A
GraphTraits<Function*> inherits from GraphTraits<BasicBlock*>, and
implements those nodes_begin()/nodes_end()
2009 Mar 13
0
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Hi Evan,
Thanks very much for the review, I am implementing your suggestions today
and will have the next patch together this weekend.
A few questions/comments:
On Thu, Mar 12, 2009 at 10:05 AM, Evan Cheng <echeng at apple.com> wrote:
>
> 1. Some of the functions that you introduced, e.g. stringifyCSRegSet
> probably ought to be "static" and ifdef'ed out when NDEBUG
2009 Aug 13
1
[LLVMdev] Graphviz and LLVM-TV
Hi Ioannis,
On Thu, 2009-08-13 at 19:31 +0100, Ioannis Nousias wrote:
> Thanks Tobi for the tip.
>
> however I also need the Data-Flow-Graph of each basic block/functions.
> As I said, I need a view of how the instructions 'link' to each other
> (via registers or memory aliasing or whatnot)
I believe that there is not yet a DOT printer for this kind of
information.
2009 Mar 05
0
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Here is an updated patch for shrink wrapping with:
- spills/restores done with stack slot stores/loads
- stack adjustment removed
- refactoring (but still in need of more)
- spill/restore insertion code unified with spill/restore placement code
Documentation available
here<http://wiki.github.com/jdmdj/llvm-work/shrink-wrapping-work>
illustrates shrink
wrapping with loops and discusses a
2013 Mar 24
0
[LLVMdev] PostOrderIterator
Hello,
I was playing with PostOrderIterator.h and I found a strange behavior.
The core class, po_iterator, is a template. One of its template
parameters is the type of the set used to store visited nodes. An
instance of that type is used by its superclass, po_iterator_storage.
Default value of the set type is llvm::SmallPtrSet. This is correct,
since po_iterator_storage::insertEdge expects that