On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> >
> > First off, several fields are marked "skip", though the
> > documents seem to strongly discourage this. For example,
> > see ssa_use_operand_t in tree.h.
>
> Was this a question? :-) Skipping is anti-social and decreases the
> flexibility of the software, that said, one can skip any field that
> doesn't need to be walked without any technical problems, as that
> field doesn't need to be walked.
Thanks. Though I didn't frame the question properly (sorry),
I wanted to know why we would want some fields of some
nodes to be skipped. Is it because:
1. we want to reduce time spent in the GC,
2. we know it doesn't matter for PCH, so we do it to
reduce the size of the PCH and its loading time,
3. some other reason?
The problem is that I see the documentation indicate
that this shouldn't be done but I see it being used with
abandon in the actual sources. Hence the query.
Your answer seems to indicate that is something
like #2 because PCH runs before any of these
fields is of any use.
> > Second, some of the tree nodes ending in variable-length
> > arrays do not seem to have the appropriate GTY "length"
> > attributes. For example, see struct tree_string's "str"
> > field in tree.h.
>
> Can be a form of skip. In general, only pointers need to be walked,
> data char [1] is just data and is handled by the size of the object
> as I recall. If you walk the PCH writer, you can watch exactly how
> it does this done if you are curious.
That array ("str") in "tree_string" is of variable length and
its length is indicated by the "length" field. So technically
at least it should be marked with a GTY((length(...)))
marker.
> > Lastly, on the gcjx-branch, a simple patch to
> > get_output_file_with_visibility() makes it recognise
> > ".hh" and ".cc" C++ source files with GTY markers.
> > My question is, is this sufficient? Do people foresee
> > any problems with this?
>
> When tested, it either works, or it doesn't. I'd rather it be tested
> and known to work, then say it looks Ok, and have it turn out to be
> incomplete. For example, the parser knows about a subset of C, if
> those files deviate from this subset too far, they can simply fail to
> work. Usually these failures are of a compile time nature, so it is
> safe to try it out by building the compiler. Better of course to
> actually test that the right thing happens.
Well, the current compiler crashes building
"java/lang/Character.java" where in the debugger I see the
Tree-SSA operands processing code "going bonkers". So
I am trying to figure out if this is because something was
yanked from under its feet by the GC or because there
is some bug in the relevant Tree-SSA code from the time
of the merge or because somehow the GCJX front-end
is not creating the trees properly or something else.
Not being familiar with GGC or Tree-SSA, tracking this
problem has been really frustrating for me. :-(
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
