Are C logical operators beging lowered too soon?

cdg@nullstone.com (Christopher Glaeser)
Mon, 13 Feb 1995 09:53:03 GMT

          From comp.compilers

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]
| List of all articles for this month |

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]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.