Related articles |
---|
[2 earlier articles] |
Re: programmer optimizations? fjh@munta.cs.mu.OZ.AU (1995-01-01) |
Re: programmer optimizations? jhowat@lucifer.cs.waikato.ac.nz (1995-01-02) |
Re: programmer optimizations? jbuck@Synopsys.COM (1995-01-02) |
Re: programmer optimizations? eru@tele.nokia.fi (Erkki Ruohtula) (1995-01-11) |
Re: programmer optimizations? conway@munta.cs.mu.OZ.AU (1995-01-05) |
Re: programmer optimizations? bill@amber.ssd.csd.harris.com (1995-01-05) |
Re: programmer optimizations? kerch@albion.camb.inmet.com (1995-01-12) |
Re: programmer optimizations? monnier@di.epfl.ch (Stefan Monnier) (1995-01-21) |
Re: programmer optimizations? synaptx!carambole!daveg@uunet.uu.net (Dave Gillespie) (1995-01-11) |
Re: programmer optimizations? det@sw.stratus.com (David Toland) (1995-01-11) |
Re: programmer optimizations? cdg@nullstone.com (1995-01-23) |
Re: programmer optimizations? hbaker@netcom.com (1995-01-27) |
Re: programmer optimizations? cdg@nullstone.com (1995-01-31) |
[5 later articles] |
Newsgroups: | comp.compilers |
From: | kerch@albion.camb.inmet.com (Kerchival F. Holt) |
Keywords: | optimize, C |
Organization: | Intermetrics, Inc. |
References: | 94-12-145 |
Date: | Thu, 12 Jan 1995 15:57:46 GMT |
I would agree with the other postings that say leave this type of
transformation up to the compiler.
I have a comment on the second transformation:
>
> replacing if ((i < 0) || (j < 0) || (k < 0))
> by if ((i | j | k) < 0)
>
This does not seem quite legal in C/C++ because it doesn't preserve the
semantics of short circuiting in the original code. That is, (j < 0) and
(k < 0) should not be evaluated if (i < 0) is true. If i, j, and k
have no side effects (they are not declared volatile) this type of
transformation would be OK.
--
----
Kerchival Holt
Intermetrics Microsystems Software Inc.
kerch@inmet.camb.inmet.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.