This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: List of simplifications we should perform
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: List of simplifications we should perform
- From: Tom Tromey <tromey at redhat dot com>
- Date: 11 May 2001 17:38:42 -0600
- Cc: dan at www dot cgsoftware dot com, gcc at gcc dot gnu dot org
- References: <200105112118.RAA26438@caip.rutgers.edu>
- Reply-To: tromey at redhat dot com
>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
Kaveh> I think most of these are already done in fold-const.c on
Kaveh> trees. How much benefit is there in redoing all the opts on
Kaveh> RTL? (Just curious, I'm sure there is some benefit.)
I think it would be interesting if these things could be defined via
some kind of lisp-like language working at the tree level (which is
what, in my naivete, I imagine the RTL plan would amount to). Then
maybe it would be easier to predicate things on whether we're
compiling for Java. (We could do this by adding `if (java)' all over
fold-const.c, but if it were a simple attribute of some sexpr, the
maintainability would go way up.)
Java has fairly strict rules about what can, cannot, and must be
folded. Right now fold() violates some of these rules. We'll
probably have to write our own fold() for Java, which is a shame.
Tom