This is the mail archive of the
mailing list for the GCC project.
Re: SIMPLE: A language-independent tree IR
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 7 Jan 2002 10:58:19 +0000 (GMT)
- Subject: Re: SIMPLE: A language-independent tree IR
On Sun, 6 Jan 2002, Diego Novillo wrote:
> Ah, now I understand. We will *not* be creating any new data
> structures. This is all done on trees. SIMPLE is just a grammar
> that specifies how the tree nodes get combined.
> In fact, I don't think we will even need to change the tree->RTL
> conversion because the C expanders will most probably be able to
> handle li-trees.
> I also don't foresee any changes to the tree SSA code. I will be
> committing to the AST branch the code that simplifies C trees in
> the next few days.
How are you representing the *partial* order constraints represented by
sequence points? The description of SIMPLE you gave suggests that it
fully serialises expression evaluation - but there should be a
language-independent representation in which the partial order constraints
are explicitly represented. How are you representing the Fortran
reassociation constraints? How are you representing the various forms of
restriction on floating point evaluation (C99, Java) discussed?
Since you are defining a new format that is supposed to have entirely
language-independent semantics, I trust you'll be committing full
documentation for these semantics (including e.g. the exact rules on what
accesses can alias what other accesses, floating-point evaluation, etc.)
to the branch along with the code, as well as documentation for the
front-end interfaces for how front ends lower their own tree codes to this
form? Because as docs co-maintainer I'll object to any new form of
internal representation ever being merged to the mainline without full
documentation of its semantics and (if the first language-independent
form) all the interfaces by which front ends generate it, so getting the
docs in shape now rather than later might be a good idea.
Joseph S. Myers