This is the mail archive of the 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

>>>>> "Diego" == Diego Novillo <> writes:

Diego> Essentially, the IR defines 14 basic statements (x and y are
Diego> variables.  a, b and c are values):
Diego> [ ... ]

Diego>      1	 x = a OP b
Diego> [ ... ]

Diego> Any tree expression that does not conform to this must be
Diego> broken down into a sequence of these 14 expressions.

Diego> Control flow is represented using all the _STMT trees defined
Diego> in c-common.def.

Why do we need all those trees when we already have _EXPR versions of
them?  For instance, why use GOTO_STMT when we have GOTO_EXPR?  Using
the _STMT forms doesn't seem any clearer to me, but it adds pressure
on the number of tree codes and it means more work for gcj hackers.

Diego>   The question here is whether the SIMPLE IR is enough to be
Diego>   used as a target language for all the front-ends we have.
Diego>   I'm particularly interested in Java and Objective-C.  Are
Diego>   there nuances in these languages that SIMPLE won't be able to
Diego>   handle?

In Java a `break' in an inner loop can break out of an outer loop (if
the user uses the `break <label'> form).  In this case the break must
also deal with enclosing `try-finally' constructs properly.  I don't
know whether capturing this information is important at this level, or
if you'd rather we just model this with goto or whatever.  (I don't
know what we do right now.)  The same holds for `continue'.

I looked through the BNF you provided but I didn't see how `goto' or
`?:' expressions are handled.  I also didn't see how exceptions are

If we do tree lowering like this before doing any tree-based
optimizations, then that will make optimizing Java bytecode generation
much harder (to the point where it is unlikely that it will be done).
This probably isn't a great loss.

Would we need to preserve VTABLE_REF trees in order to keep vtable GC
working?  (gcj doesn't use this yet, but maybe some day it will.)

The ordering constraints that Joseph mentions would be useful for gcj.
The Java language spec specifies ordering in many situations that C
does not (e.g., function call arguments are evaluated left-to-right).

I'm interested in using Java's stricter type system to let us do
optimizations that are either harder in other languages
(devirtualizing method calls, maybe?) or that are simply Java-specific
(removing redundant synchronizations after inlining, removing
redundant cast checks, array length checks, or class initializations).
For devirtualizing in particular I'm concerned that an overly simple
format will make recognizing virtual method calls hard.

There may be other Java-related things I haven't thought of.


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