Re: Are C logical operators being lowered too soon? (Christopher Glaeser)
Mon, 27 Feb 1995 08:31:19 GMT

          From comp.compilers

Related articles
Re: Are C logical operators being lowered too soon? (1995-02-27)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Christopher Glaeser)
Keywords: C, optimize
Organization: Compilers Central
Refercenes: 95-02-147
Date: Mon, 27 Feb 1995 08:31:19 GMT (Christopher Glaeser) writes:
> The logical operators && and || are relatively common in C programs.
> However, analysis shows that many compilers fail to optimize
> expressions that contain logical operators. (Bill Leonard) writes:
> ... the likelihood of finding a CSE
> opportunity for && or || is so low that this complication is just not worth
> it.

What evidence do you have to support the assertion that CSE opportunities
for && and || are not likely? Are you referring ONLY to the result of the
logical expression, or do you also include CSE's within a logical
expression, an example being ((e1 op e2) || (e1 op e3))?

When designing new compiler performance tests for Nullstone, I review
applications and benchmarks to better understand how various language
features are used. In a recent study of logical expressions, I observed
that logical expressions are common in some C applications, and CSE's
within logical expressions are also common.

Consider the GNU gcc compiler (which is both a *real* application and a
SPEC benchmark). This application defines approximately 1000 macros in
the header files. A random sampling suggests that about 15% of these
macros contain logical expressions, and over 50% of these logical
expressions contain CSE's.

An example is the following:

    #define CONSTANT_ADDRESS_P(X) \
      || GET_CODE (X) == CONST_INT || GET_CODE (X) == HIGH \
      || (GET_CODE (X) == CONST \
              && ! (flag_pic && pic_address_needs_scratch (X))))

Note that the argument (X) is used six times across the logical expressions.
Scanning the .c source files reveals code fragments like the following:

    ... && CONSTANT_ADDRESS_P (XEXP (DECL_RTL (exp), 0)))) ...

When expanded, this code fragment becomes:

    && (((((((exp)->decl.rtl))->fld[0].rtx))->code) == LABEL_REF
    || ((((((exp)->decl.rtl))->fld[0].rtx))->code) == SYMBOL_REF
    || ((((((exp)->decl.rtl))->fld[0].rtx))->code) == CONST_INT
    || ((((((exp)->decl.rtl))->fld[0].rtx))->code) == HIGH
    || (((((((exp)->decl.rtl))->fld[0].rtx))->code) == CONST
    && ! (flag_pic && pic_address_needs_scratch (((((exp)->decl.rtl))->fld[0].rtx)))))))
        return change_address (((exp)->decl.rtl) , VOIDmode,
copy_rtx (((((exp)->decl.rtl))->fld[0].rtx)));

This example is not contrived nor unique. Scanning other macro definitions
within gcc and other applications revealed many similar examples.

Best regards,
Christopher Glaeser
Nullstone Corporation

Post a followup to this message

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