public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [Fwd: [Fwd: GCC tree access]]
@ 2002-12-06  9:05 Jeffrey Richardson
  2002-12-06 10:41 ` Pop Sébastian
  0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey Richardson @ 2002-12-06  9:05 UTC (permalink / raw)
  To: gcc



Jeff Richardson wrote:

> Jeff Richardson wrote:
>
> > Hello,
> >
> > I am interested in developing a combination "intelligent editor" and
> > source browser using the tree structure created internally by GCC, as
> > described in the article on trees in the GCC Internals manual.
> >
> > I see the example "process_stmt" function in the article on Function
> > Bodies.  I also see the function "expand_stmt" in the file c-semantics.c
> > which is called by a number of functions including several genrtl_
> > functions, and the c_expand_body function.  The c_expand_body function
> > is in turn called from several places including finish_function in
> > c-decl.c.
> >
> > My question is this:  if I write my own version of "precess_stmt" which
> > uses the macros to access various tree information and write it out to a
> > file, where is the best place to call my function?  Can it be called
> > from a single location (such as finish_function), and still have access
> > to the full tree structure?
> >
> > Also, what is the "permanence" of the tree structure.  As a source file
> > is parsed, and the tree structure is constructed, is there a point at
> > which branches of the tree are discarded because they are no longer
> > needed (e.g. when a function has been completed), or is there a point at
> > which a complete tree exists for the entire source file, which would
> > therefore be the best time to call a function to output a "snapshot" of
> > the tree?  (I guess this is actually a re-statement of my first
> > question.)
> >
> > If there are any examples or code fragments of similar applications that
> > you can share with me, I would very much appreciate it.  I am primarily
> > interest in processing C source code right now, but would like to make
> > the application robust enough to handle C++ as well, and take advantage
> > of the fact that they are both parsed into a tree.
> >
> > Thankyou,
> >
> > Jeff Richardson
> > jlrichardson@link.com
> > (407)382-1580

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Fwd: [Fwd: GCC tree access]]
  2002-12-06  9:05 [Fwd: [Fwd: GCC tree access]] Jeffrey Richardson
@ 2002-12-06 10:41 ` Pop Sébastian
  2003-03-13 19:30   ` GCC tree access & Pretty-print Jeffrey Richardson
  2003-03-13 20:48   ` another tree access question Jeffrey Richardson
  0 siblings, 2 replies; 6+ messages in thread
From: Pop Sébastian @ 2002-12-06 10:41 UTC (permalink / raw)
  To: Jeffrey Richardson; +Cc: gcc

Hi,

On Fri, Dec 06, 2002 at 11:43:32AM -0500, Jeffrey Richardson wrote:
> > >
> > > I am interested in developing a combination "intelligent editor" and
> > > source browser using the tree structure created internally by GCC, as
> > > described in the article on trees in the GCC Internals manual.
> > >
Have a look at http://gcc.gnu.org/projects/tree-ssa/tree-browser.html
This is (for the moment) just a debugging tool, but it could be extended 
into an interactive source browsing/editing tool.

> > > My question is this:  if I write my own version of "precess_stmt" which
> > > uses the macros to access various tree information and write it out to a
> > > file, where is the best place to call my function?  Can it be called
> > > from a single location (such as finish_function), and still have access
> > > to the full tree structure?
> > >
Yes. 
You can use TB for experimenting during a gdb session and see what information 
is available at a given point of the compiler.

Ouch... I just realised that there's no link to a page explaining how to 
debug GCC using GDB.  Is there any page that contains these bits?
Otherwise I'll write one from scratch.

> > > Also, what is the "permanence" of the tree structure.  
For the moment in tree-ssa branch you cannot store tree structures into a file.
However this operation was implemented in pch-branch, and thus it could be 
included in tree-ssa-branch once pch-branch stabilize.

> > > As a source file
> > > is parsed, and the tree structure is constructed, is there a point at
> > > which branches of the tree are discarded because they are no longer
> > > needed (e.g. when a function has been completed), 
yes, once trees were translated into RTL garbage collector is called and 
tree structures for function's body are freed.  

I think that there's a possiblilty to make GCC keep all functions from a 
compilation unit in memory simply by avoiding to go into rest_of_compilation.

For handling projects with multiple files we'll need a load_tree operation
(already implemented in pch-branch I think).

A source editing tool working on top of GCC could improve development style,
productivity, and code understandability (for example class hierarchy, call-
graph,... are for free when you work with ASTs).  Moreover the programmer
could focus on a small part of the code and optimize it locally.  One could 
even imagine more interaction when the compiler could extract information by 
questioning directly the programmer.

> > > or is there a point at
> > > which a complete tree exists for the entire source file, which would
> > > therefore be the best time to call a function to output a "snapshot" of
> > > the tree?  (I guess this is actually a re-statement of my first
> > > question.)
> > >
just before genrtl_ expanders (expr.c).

> > > If there are any examples or code fragments of similar applications that
> > > you can share with me, I would very much appreciate it.  

Yes, two weeks ago I contributed tree-browser.c in tree-ssa branch.

For checking this branch out, have a look at the instructions:
http://gcc.gnu.org/projects/tree-ssa/index.html


Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* GCC tree access & Pretty-print
  2002-12-06 10:41 ` Pop Sébastian
@ 2003-03-13 19:30   ` Jeffrey Richardson
  2003-03-14 14:56     ` Pop Sébastian
  2003-03-13 20:48   ` another tree access question Jeffrey Richardson
  1 sibling, 1 reply; 6+ messages in thread
From: Jeffrey Richardson @ 2003-03-13 19:30 UTC (permalink / raw)
  To: Pop Sébastian; +Cc: gcc

Pop,

Thankyou for the information you sent me last December regarding trees.  I have not
had time until now to work on this pet project of mine to create a source browser,
but I recently picked it up again.  Of course, I have had to refamiliarize myself
with the little bit of code I had viewed before to see how to get the information I
want.

I was wondering if you (or anyone else at gcc.gnu.org) could tell me how the
pretty-print capability works?  I see alot of code starting with
pp_c_pretty_printer_init, but I cannot decern how it is used.  Is this a debugging
capability that has to be turned on in the code?  If so, how do you do so?

As before, any examples that anyone can provide for either the pretty-print stuff,
or accessing trees in general would be greatly appreciated.

Also, If anyone has instructions on the best way quickly test changes to the gcc
code, I would like to see them.  I downloaded the CVS tree, did a "configure" to
/usr/local, did a "make bootstrap", and then a "make install".  I find that to test
changes I need to do a "make" in objdir, and then do another "make install" (as
root), to get the changes.  The "make install" takes quite a bit of time.  Is there
a faster way to test changes that I make to the code?

Thanks for the help

Jeff Richardson
jlrichardson@link.com

Pop Sébastian wrote:

> Hi,
>
> On Fri, Dec 06, 2002 at 11:43:32AM -0500, Jeffrey Richardson wrote:
> > > >
> > > > I am interested in developing a combination "intelligent editor" and
> > > > source browser using the tree structure created internally by GCC, as
> > > > described in the article on trees in the GCC Internals manual.
> > > >
> Have a look at http://gcc.gnu.org/projects/tree-ssa/tree-browser.html
> This is (for the moment) just a debugging tool, but it could be extended
> into an interactive source browsing/editing tool.
>
> > > > My question is this:  if I write my own version of "precess_stmt" which
> > > > uses the macros to access various tree information and write it out to a
> > > > file, where is the best place to call my function?  Can it be called
> > > > from a single location (such as finish_function), and still have access
> > > > to the full tree structure?
> > > >
> Yes.
> You can use TB for experimenting during a gdb session and see what information
> is available at a given point of the compiler.
>
> Ouch... I just realised that there's no link to a page explaining how to
> debug GCC using GDB.  Is there any page that contains these bits?
> Otherwise I'll write one from scratch.
>
> > > > Also, what is the "permanence" of the tree structure.
> For the moment in tree-ssa branch you cannot store tree structures into a file.
> However this operation was implemented in pch-branch, and thus it could be
> included in tree-ssa-branch once pch-branch stabilize.
>
> > > > As a source file
> > > > is parsed, and the tree structure is constructed, is there a point at
> > > > which branches of the tree are discarded because they are no longer
> > > > needed (e.g. when a function has been completed),
> yes, once trees were translated into RTL garbage collector is called and
> tree structures for function's body are freed.
>
> I think that there's a possiblilty to make GCC keep all functions from a
> compilation unit in memory simply by avoiding to go into rest_of_compilation.
>
> For handling projects with multiple files we'll need a load_tree operation
> (already implemented in pch-branch I think).
>
> A source editing tool working on top of GCC could improve development style,
> productivity, and code understandability (for example class hierarchy, call-
> graph,... are for free when you work with ASTs).  Moreover the programmer
> could focus on a small part of the code and optimize it locally.  One could
> even imagine more interaction when the compiler could extract information by
> questioning directly the programmer.
>
> > > > or is there a point at
> > > > which a complete tree exists for the entire source file, which would
> > > > therefore be the best time to call a function to output a "snapshot" of
> > > > the tree?  (I guess this is actually a re-statement of my first
> > > > question.)
> > > >
> just before genrtl_ expanders (expr.c).
>
> > > > If there are any examples or code fragments of similar applications that
> > > > you can share with me, I would very much appreciate it.
>
> Yes, two weeks ago I contributed tree-browser.c in tree-ssa branch.
>
> For checking this branch out, have a look at the instructions:
> http://gcc.gnu.org/projects/tree-ssa/index.html
>
> Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* another tree access question
  2002-12-06 10:41 ` Pop Sébastian
  2003-03-13 19:30   ` GCC tree access & Pretty-print Jeffrey Richardson
@ 2003-03-13 20:48   ` Jeffrey Richardson
  2003-03-14 15:51     ` Pop Sébastian
  1 sibling, 1 reply; 6+ messages in thread
From: Jeffrey Richardson @ 2003-03-13 20:48 UTC (permalink / raw)
  To: Pop Sébastian; +Cc: gcc

Pop,

I still have the question I asked in my original email:  if I have a new function
to print out  tree information (or for that matter wanted to use an existing
function such as debug_tree or print_node), and I want to find a single place in
the gcc code to call this function and access the entire tree for the program unit
currently being compiled, where would I place the call to the function?

In other words, is there any place in the code where I can get an address of a tree
which represents the entire program unit?  If so, where is it?

As before, any examples would be greatly appreciated.

Also, you mentioned that there was no documentation describing how to use gdb on
the gcc code, and make use of your tree-browser.  Is there any documentation now?

Thanks again,

Jeff Richardson
jlrichardson@link.com

Pop Sébastian wrote:

> Hi,
>
> On Fri, Dec 06, 2002 at 11:43:32AM -0500, Jeffrey Richardson wrote:
> > > >
> > > > I am interested in developing a combination "intelligent editor" and
> > > > source browser using the tree structure created internally by GCC, as
> > > > described in the article on trees in the GCC Internals manual.
> > > >
> Have a look at http://gcc.gnu.org/projects/tree-ssa/tree-browser.html
> This is (for the moment) just a debugging tool, but it could be extended
> into an interactive source browsing/editing tool.
>
> > > > My question is this:  if I write my own version of "precess_stmt" which
> > > > uses the macros to access various tree information and write it out to a
> > > > file, where is the best place to call my function?  Can it be called
> > > > from a single location (such as finish_function), and still have access
> > > > to the full tree structure?
> > > >
> Yes.
> You can use TB for experimenting during a gdb session and see what information
> is available at a given point of the compiler.
>
> Ouch... I just realised that there's no link to a page explaining how to
> debug GCC using GDB.  Is there any page that contains these bits?
> Otherwise I'll write one from scratch.
>
> > > > Also, what is the "permanence" of the tree structure.
> For the moment in tree-ssa branch you cannot store tree structures into a file.
> However this operation was implemented in pch-branch, and thus it could be
> included in tree-ssa-branch once pch-branch stabilize.
>
> > > > As a source file
> > > > is parsed, and the tree structure is constructed, is there a point at
> > > > which branches of the tree are discarded because they are no longer
> > > > needed (e.g. when a function has been completed),
> yes, once trees were translated into RTL garbage collector is called and
> tree structures for function's body are freed.
>
> I think that there's a possiblilty to make GCC keep all functions from a
> compilation unit in memory simply by avoiding to go into rest_of_compilation.
>
> For handling projects with multiple files we'll need a load_tree operation
> (already implemented in pch-branch I think).
>
> A source editing tool working on top of GCC could improve development style,
> productivity, and code understandability (for example class hierarchy, call-
> graph,... are for free when you work with ASTs).  Moreover the programmer
> could focus on a small part of the code and optimize it locally.  One could
> even imagine more interaction when the compiler could extract information by
> questioning directly the programmer.
>
> > > > or is there a point at
> > > > which a complete tree exists for the entire source file, which would
> > > > therefore be the best time to call a function to output a "snapshot" of
> > > > the tree?  (I guess this is actually a re-statement of my first
> > > > question.)
> > > >
> just before genrtl_ expanders (expr.c).
>
> > > > If there are any examples or code fragments of similar applications that
> > > > you can share with me, I would very much appreciate it.
>
> Yes, two weeks ago I contributed tree-browser.c in tree-ssa branch.
>
> For checking this branch out, have a look at the instructions:
> http://gcc.gnu.org/projects/tree-ssa/index.html
>
> Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC tree access & Pretty-print
  2003-03-13 19:30   ` GCC tree access & Pretty-print Jeffrey Richardson
@ 2003-03-14 14:56     ` Pop Sébastian
  0 siblings, 0 replies; 6+ messages in thread
From: Pop Sébastian @ 2003-03-14 14:56 UTC (permalink / raw)
  To: Jeffrey Richardson; +Cc: gcc

Hi,

On Thu, Mar 13, 2003 at 01:37:15PM -0500, Jeffrey Richardson wrote:
> I was wondering if you (or anyone else at gcc.gnu.org) could tell me how the
> pretty-print capability works?  I see alot of code starting with
> pp_c_pretty_printer_init, but I cannot decern how it is used.  Is this a debugging
> capability that has to be turned on in the code?  If so, how do you do so?
> 
These functions are used in mainline for printing diagnostic messages (such as 
errors or warnings).  In the tree-ssa branch we have a set of functions 
debug_generic_*, debug_c_* that we use for dumping the trees in a c-like syntax.  
The dumped format is not compilable.  

> As before, any examples that anyone can provide for either the pretty-print stuff,
> or accessing trees in general would be greatly appreciated.
> 

For accessing trees you could follow the instructions given in: 
-  http://gcc.gnu.org/bugs/reghunt.html  for getting and installing the sources,
-  http://gcc.gnu.org/bugs/segfault.html  gives some instructions for debugging GCC.

You can for example insert a "browse_tree (fndecl);" in 
"tree-optimize.c: optimize_function_tree (fndecl)"
rebuild the compiler and compile with -O2 foo.c.

You can insert this kind of code where you want in the compiler. You can also call 
the tree browser from gdb "call browse_tree (some_tree_node)".  There are also 
the "debug_*" functions that dump on stderr useful information about structures.

> Also, If anyone has instructions on the best way quickly test changes to the gcc
> code, I would like to see them.  I downloaded the CVS tree, did a "configure" to
> /usr/local, did a "make bootstrap", and then a "make install".  I find that to test
> changes I need to do a "make" in objdir, and then do another "make install" (as
> root), to get the changes.  The "make install" takes quite a bit of time.  Is there
> a faster way to test changes that I make to the code?
> 
You can use the cc1* compilers from objdir/gcc/ once you have built GCC: 
for example "objdir/gcc/cc1 -O2 foo.c", or 
"gdb objdir/gcc/cc1" and then "(gdb) run -O2 foo.c"

	Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: another tree access question
  2003-03-13 20:48   ` another tree access question Jeffrey Richardson
@ 2003-03-14 15:51     ` Pop Sébastian
  0 siblings, 0 replies; 6+ messages in thread
From: Pop Sébastian @ 2003-03-14 15:51 UTC (permalink / raw)
  To: Jeffrey Richardson; +Cc: gcc

On Thu, Mar 13, 2003 at 03:22:13PM -0500, Jeffrey Richardson wrote:
> function such as debug_tree or print_node), and I want to find a single place in
> the gcc code to call this function and access the entire tree for the program unit
> currently being compiled, where would I place the call to the function?
> 
You can have a look at the call graph: cgraphunit.c, cgraph.c

/* Analyze the whole compilation unit once it is parsed completely.  */

void
cgraph_finalize_compilation_unit ()

/* Dump the callgraph.  */

void
dump_cgraph (f)

> In other words, is there any place in the code where I can get an address of a tree
> which represents the entire program unit?  If so, where is it?
> 
in c-objc-common.c you have the following 

  if (flag_unit_at_a_time)
    {
      cgraph_finalize_compilation_unit ();
      cgraph_optimize ();
    }

I think that at this point you get the entire unit translated into trees.

You can insert a "dump_cgraph (stderr);" before and after the "cgraph_optimize ();", 
then recompile GCC and test the cc1 compiler using:
"objdir/gcc/cc1 -funit-at-a-time foo.c" or something similar.

	Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-03-14 13:46 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-06  9:05 [Fwd: [Fwd: GCC tree access]] Jeffrey Richardson
2002-12-06 10:41 ` Pop Sébastian
2003-03-13 19:30   ` GCC tree access & Pretty-print Jeffrey Richardson
2003-03-14 14:56     ` Pop Sébastian
2003-03-13 20:48   ` another tree access question Jeffrey Richardson
2003-03-14 15:51     ` Pop Sébastian

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).