Re: programmer optimizations?

"Virendra K. Mehta" <c1veeru@WATSON.IBM.COM>
Thu, 2 Feb 1995 05:58:45 GMT

          From comp.compilers

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


Post a followup to this message

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