This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]