Re: Unsafe optimzations (John Mashey)
19 Aug 91 03:15:36 GMT

          From comp.compilers

Related articles
Re: Writing fast compilers... (1991-08-16)
Unsafe optimzations (1991-08-17)
Re: Unsafe optimzations (1991-08-19)
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: (John Mashey)
Keywords: optimize, Fortran, design
Organization: MIPS Computer Systems, Inc.
References: <1991Aug15.205912.6553@sono.uucp> 91-08-072 91-08-078
Date: 19 Aug 91 03:15:36 GMT

In article 91-08-078 (Michael O'Dell) writes:
>In the example case of multi-hop pointer chasing in C, there is no way in the
>world for any compiler to divine whether that is safe to eliminate such
>chains ("volatile" declarations being a cruel hoax at best). And if the

I think this is too strong a statement... MIPS compilers (and at least
a few others surely must) can be quite sure in some cases that it is
perfectly safe to eliminate such chains, and do. Of course, there are
many cases in which it would be safe, but the compiler cannot know,
whereas a human might. (And I think this is what Mike meant (?)

However there are still many cases where it
is possible for the compiler to know:
a = p->q->r;
b = p->q->t;
suppose a and b are register variables: it is clearly safe to genrate code
lw r1,p

lw r2,0(r1) q
lw r3,4(r2) r

lw r4,8(r2) t (skipping reload of r2)

However, any good global optimizer does enough tracking of addresses,
and certainly knowing if the address of a variable has potentially
gotten loose, to effectively act like local variables are
declared register.

I have NO idea of the statistical usefulness of such optimizations.
I do KNOW that it works, and that simple changes that moved code from
safe to unsafe caused the extra reload to happen (as in making "a"
an external variable.)
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650


Post a followup to this message

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