Related articles |
---|
[9 earlier articles] |
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) |
Re: programmer optimizations? c1veeru@WATSON.IBM.COM (Virendra K. Mehta) (1995-02-02) |
Re: programmer optimizations? hbaker@netcom.com (1995-02-01) |
Re: programmer optimizations? bill@amber.ssd.csd.harris.com (1995-02-01) |
Re: programmer optimizations? gnb@bby.com.au (1995-02-02) |
Re: programmer optimizations? rfg@rahul.net (Ronald F. Guilmette) (1995-02-04) |
Newsgroups: | comp.compilers |
From: | "Virendra K. Mehta" <c1veeru@WATSON.IBM.COM> |
Keywords: | optimize, comment |
Organization: | Compilers Central |
References: | 95-01-047 |
Date: | Thu, 2 Feb 1995 05:58:45 GMT |
[ Christopher Glaeser penned : ]
|o|
|o| > > replacing (n / 4)
|o| > > by (n >> 2)
|o|
|o| > Unfortunately it seems you cannot always trust the compiler writers
|o| > to do the right thing here.
This brings to mind another related optimization. A compiler cannot optimize
based on a pointer that has come in as a formal parameter, or which gets
passed to a function. For example, consider
fn(int *pi)
{
*pi = 1;
fn2 ();
...
if (*pi == 1)
...
else
...
...
}
Here, it can't be assumed that pi would not have been modified by the call to
fn2. Thus the compiler cannot do away with the 'if' check (this is a very
simplified example). This is further reinforced if 'pi' is passed as an
argument to fn2. Technically speaking, pi is placed on an alias list. Same
happens for an auto variable, if its address is taken once. Most optimizations
on it are suspended thereafter.
This can be pretty frustrating if there are a lot of pointer variables passed
to a function and used deep inside a loop. The compiler refuses to perform
many simple common-subexpression-elimination optimizations and accesses memory
repeatedly when the contents can be placed in a register once for all. The
problem here is that the programmer KNOWS that the variable need not be placed
on the alias list. I think there should be some way for him to be able to
communicate this to the compiler. (I've been trying to optimize a lot of such
code currently, part of a scientific software).
I remember reading somewhere that C had a stillborn reserved word 'noalias'.
Was it supposed to convey the same meaning ? Why was it discontinued and how
good an idea would it be to revive it ?
Is there a general set of guidelines that should be followed by programmers to
ensure these optimizations ? (I know that compilers can't take a chance there,
unless a hint is given to them by the programmer).
Comments anyone ?
Ciao!
Veeru.
--
============================================================================
Virendra K Mehta c1veeru@watson.ibm.com
Wipro Systems Ltd. viren@wipsys.soft.net
[There have been a variety of C extensions proposed for "noalias" or
"restricted" pointers. Noalias failed to make it into the standard because
they couldn't get a clean enough definition of it in the time frame they had.
Restricted pointers may show up in C9X. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.