Related articles |
---|
Are C logical operators beging lowered too soon? cdg@nullstone.com (1995-02-13) |
Re: Are C logical operators beging lowered too soon? cliffc@crocus.hpl.hp.com (1995-02-14) |
Optimizing Across && And || bart@cs.uoregon.edu (1995-02-15) |
Re: Optimizing Across && And || preston@tera.com (1995-02-18) |
Re: Are C logical operators beging lowered too soon? bill@amber.ssd.csd.harris.com (1995-02-19) |
Re: Optimizing Across && And || bill@amber.ssd.csd.harris.com (1995-02-19) |
Re: Optimizing Across && And || bart@cs.uoregon.edu (1995-02-21) |
[6 later articles] |
Newsgroups: | comp.compilers |
From: | cdg@nullstone.com (Christopher Glaeser) |
Keywords: | C, optimize, question, comment |
Organization: | Compilers Central |
Date: | Mon, 13 Feb 1995 09:53:03 GMT |
The logical operators && and || are relatively common in C programs.
However, analysis shows that many compilers fail to optimize
expressions that contain logical operators.
The table below shows the Nullstone results for CSE Elimination
within a basic block. The code in this particular series of
tests has a form something like:
i1 = x + y;
i2 = x + y;
where the '+' operator is replaced with one of '-', '*', ...
The performance of the generated code is measured and compared to
hand-optimized code. This ratio is between 0% and 100%, where
100% is a perfect score (plus or minus a couple percent for clock
inaccuracies). A Nullstone Ratio which is significantly less
than 100% means the compiler failed to perform the optimization
under test.
Below is a sample of results for three SPARC compilers. (I
don't mean to pick on these three compilers; I've evaluated
many other compilers as well, and the results are similar).
Note that all three compilers optimized all of the
non-sequence operators in the list (97% to 100%), but failed
to optimize logical and (&&) (13% to 17%).
================================================================
NULLSTONE Release 3.8.4
Operator Metaware 2.3 GNU 2.5.8 SunPro 3.0.1
+ 98% 98% 100%
- 98% 98% 100%
* 100% 99% 100%
/ 97% 98% 100%
% 100% 100% 99%
& 98% 98% 99%
| 99% 97% 99%
^ 98% 98% 100%
<< 99% 99% 99%
>> 99% 99% 100%
&& 13% 17% 17%
================================================================
In other words, many compilers fail to optimize code fragments of
the form:
i1 = x && y;
i2 = x && y;
and replace it with:
reg = x && y;
i1 = reg;
i2 = reg;
This is not only true for CSE Elimination, but many other optimizations
as well. For example, some compilers can hoist (x + y) in:
for (i = ...) a[i] = x + y;
but these compilers fail to hoist (x && y) in:
for (i = ...) a[i] = x && y;
Of course, (x && y) is quite different from many other operators due
to the sequence point, which, in general, requires a branch. However,
is it possible that compilers are lowering && and || to if-then-else
too early in the compiler, and thus making it much more difficult
to perform optimizations which would otherwise be easier to support?
Also, I am very interested in hearing about any compilers that will
perform CSE Elimination, hoisting, etc, on && and || expressions, and
any comments about how on it was implemented.
Best regards,
Christopher Glaeser
Nullstone Corporation
[My guess is that nobody bothers to optimize this, because && and || rarely
occur outside of a truth value context in if, while, or for. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.