Proposed new tree node for gcc

Proposed new tree node for gcc

[Alexandre Petit-Bianco]

Hi,

This email proposes the introduction of a new tree node for gcc,
aiming at encapsulating other nodes with file location information. 

The idea is that there are languages like Java that require the entire
source file to be parsed before tree nodes can be built or completed,
which means that as we're encountering identifiers and expressions, we
need hook them to file location information so we can pinpoint errors
during the check of the semantic and generate debug information during
the expansion phase.

We (Per Bothner and myself) propose the definition of a new tree node
called EXPR_WITH_FILE_LOCATION defined as a 'e' node. The struct
tree_exp is big enough to provide us with the appropriate storage
space: `operands[]' can be used to store the encapsulated node,
`complexity' is big enough to store line (20 bit) and column numbers
(12 bit); `common.chain' can provide a hook for filename information.

We started to experiment with an implementation. It turns out that,
besides the definition of the new tree node in tree.def, some macro
definitions in tree.h and a function in tree.c, print-tree.c needs to
be slightly altered; expand_expr need to be modified to apply
expand_expr to the operand node of the encapsulating node, possibly
calling emit_line_note with the relevant file location information.

The file http://www.cygnus.com/~apbianco/gcc-patch capture the changes
we think are necessary. Let me know what you're thinking about it. So
far, everything, down to the name of the macros and functions is left
open for discussion.

Thanks,

-- Alex

Re: Proposed new tree node for gcc

[Richard Henderson]

On Tue, Mar 24, 1998 at 12:51:48PM -0800, Alexandre Petit-Bianco wrote:
> We (Per Bothner and myself) propose the definition of a new tree node
> called EXPR_WITH_FILE_LOCATION defined as a 'e' node. The struct
> tree_exp is big enough to provide us with the appropriate storage
> space: `operands[]' can be used to store the encapsulated node,
> `complexity' is big enough to store line (20 bit) and column numbers
> (12 bit); `common.chain' can provide a hook for filename information.

While I think that the idea is good, doing such gross things with
overloading `common.chain' is very bad.  Defining a new struct is
not so difficult, and should be the way this is accomplished.


r~

Re: Proposed new tree node for gcc

[Jeffrey A Law]

  In message < 199803242051.MAA20731@sendai.cygnus.com. >you write:
  > We (Per Bothner and myself) propose the definition of a new tree node
  > called EXPR_WITH_FILE_LOCATION defined as a 'e' node. The struct
  > tree_exp is big enough to provide us with the appropriate storage
  > space: `operands[]' can be used to store the encapsulated node,
  > `complexity' is big enough to store line (20 bit) and column numbers
  > (12 bit); `common.chain' can provide a hook for filename information.
Why not just define a new structure and add it to the tree_node
union?  You could make the line/column #s bitfields.


jeff

Re: Proposed new tree node for gcc

[Per Bothner]

Alexandre Petit-Bianco <apbianco@cygnus.com> wrote:
> We (Per Bothner and myself) propose the definition of a new tree node
> called EXPR_WITH_FILE_LOCATION defined as a 'e' node.

That should be a '1' node.

There should also be a macro like:

#define EXPR_WFL_SET_LINE_COLUMN(NODE, LINE, COL) \
  (EXPR_WFL_LINECOL(NODE) = ((LINE) << 12) | ((COL) & 0xfff))

Richard Henderson <rth@cygnus.com> wrote:

> While I think that the idea is good, doing such gross things with
> overloading `common.chain' is very bad.  Defining a new struct is
> not so difficult, and should be the way this is accomplished.

While I am not religious on the subject, I do think it is
desirable to not waste space.  (I know - this is a goal that
is foreign to gcc ...)  If we are going to represent entire
programs (including imported files) as tree nodes, there may be
a lot of EXPR_WITH_FILE_LOCATION nodes.  Wasting a word for each
seems a shame.

There is already precdent for overloading common.chain in TYPE_STUB_DECL,
so it is too late to argue that common.chain should only be used to link
things together into a list.

Note that you could not use TREE_CHAIN to chain arbitrary expressions
together, since declarations are expressions, but the TREE_CHAIN of a
declaration is usually in use.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: Proposed new tree node for gcc

[Per Bothner]

Jeffrey A Law <law@cygnus.com> writes:
> Why not just define a new structure and add it to the tree_node
> union?  You could make the line/column #s bitfields.

We could do that, but it would waste one word per EXPR_WITH_FILE_LOCATION
node.  Same reason for using the TREE_CHAIN for the filename.

One might say that this is excessive or premature space optimization.
However, we know that many large compiles have problems due to large
memory usage, so we might as well be economical, especially when
there is no real reason not to be.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: Proposed new tree node for gcc

[Per Bothner]

> I think the only time we've had any significant problems with the
> tree space 

But past experience is not relevant here.  Our plan for Java
is to represent an entire class and maybe an entire program using
tree nodes.  I don't know if this is practical; the alternative
is parsing each source file twice.  In the past, we have only
represented a single statement using tree nodes.

> I'd kinda prefer to wait until we know that we're causing a memory
> issues before making a hack like is being suggested.

First, I don't think it's much of a hack. Less code is being changed
that if we had to define a a new struct type, and it makes perfect
sense to me to consider a EXPR_WITH_LINE (or whatever it's called)
as a unary no-op conversion with some annotations.

Secondly, we *know* there will be memory issues.

Perhaps the real issue is that we don't do far enough.  We might
consider removing 'chain' from common, and keeping it only where
it is useful (basically declarations and TREE_LIST).  But that is
more work than I feel like doing now ...

	--Per

Re: Proposed new tree node for gcc

[Jeffrey A Law]

  In message < 199803280914.BAA22817@cygnus.com >you write:
  > One might say that this is excessive or premature space optimization.
  > However, we know that many large compiles have problems due to large
  > memory usage, so we might as well be economical, especially when
  > there is no real reason not to be.
The vast majority of the memory usage problems have been in the
optimizers -- usually due to the need to allocate 1d and 2d arrays
based on register #s or INSN_UIDs.

I think the only time we've had any significant problems with the
tree space was when we used to have -fcombine-statics, which went
around copying nodes from temporary trees into permanent trees.

I'd kinda prefer to wait until we know that we're causing a memory
issues before making a hack like is being suggested.

jeff