This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa/mainline PATCH] fold "test"==0 into constant
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 06 Nov 2003 22:20:49 +0100
- Subject: Re: [tree-ssa/mainline PATCH] fold "test"==0 into constant
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <Pine.LNX.email@example.com>
Roger Sayle wrote:
Longer-term, I think what constant folding really needs are two
functions tree_expr_lower_bound and tree_expr_upper_bound, where we
can implement some form of interval arithmetic. Then the two current
functions tree_expr_nonnegative_p and tree_expr_nonzero_p can easily
be implemented by testing the returned bounds against zero. This will
provide for more accurate implementations, but also enable many more
optimizations, for example, comparisons against any integer constant,
or comparisons between expressions with non-overlapping bounds.
For example, we could remove bounds checks from "switch (x & 7)"...
Just this week I ran into the following:
An important part of our Numerical Weather Forecasting Program has to
know about the saturation (water) vapor pressure as function of temperature.
This relation is well known, but (because it involves the exponential
function) quite expensive to compute - so we tabulate the results in the
relevant temperature interval (173 - 373 Kelvin) in an array for every
Therefore, basically, in the code, you're left with:
psat(t) = tpsat(nint(t*100.0))
Now it would be very nice if we could indicate to the backend that the
expression "nint(t*100.0)" actually has values between 17300 and 37300,
so that the nint could be evaluated as int(t*100.0 + 0.5) instead of the
far more complicated expression due to Fortran 95's semantics (which of
course have to cater for negative numbers).
On our Sun, just being able to inline the nint got us a 30 % improvement
in run time (over all) - so it's obvious what halving the number of
instructions will buy us.
Toon Moene - mailto:firstname.lastname@example.org - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)