Newsgroups: | comp.compilers |
From: | moss@cs.umass.edu (Eliot Moss) |
Organization: | Dept of Comp and Info Sci, Univ of Mass (Amherst) |
Date: | Thu, 30 Jul 1992 00:08:32 GMT |
Keywords: | C, storage |
References: | 92-07-064 92-07-089 |
graham@maths.su.oz.au (Graham Matthews) said:
> (Hans Boehm) writes:
>>a) (the one I'd personally most like to see fixed) The treatment of
>>source languages that require garbage collection is tricky.
> I am not sure I understand what you are talking about here Hans. As
> far as I can see if the C code you produce is not safe in the presence
> of garbage collection then you are generating incorrect C code. There
> is nothing in C that makes it "garbage collection unsafe" even with a
> non-conservative garbage collection.
Suppose we have something like the following code:
int *p, *q;
int i;
for (i = 0; i < 100; i++)
p[i] = q[i];
Since C compilers are generally written assuming that allocated things do
not move during execution, we might get code like this for a machine
supporting two index registers in an addressing mode:
ld rp,p ; rp <- p
addi rl,rp,400 ; rl <- p + 100 * 4 (4 byte integers)
ld rq,q ; rq <- q
sub rq,rq,rp ; rq <- rq - rp
label: ld rx,0(rp,0) ; rx <- p[i]
st rx,0(rp,rq) ; q[i] <- rx
addi rp,rp,4 ; rp <- rp + 4
blt rp,rl,label ; loop if rp < rl (rl = the limit)
This appears to be perfectly legal code, yet it is possible that no
pointer to q exists, and we might gc (you might argue not in this case,
but I can add a call in the loop or something and fix that, or we can say
there are multiple threads and another thread causes gc).
This is the kind of subtle transformation that Hans was referring to. Note
that the transformation here improves performance by reducing the number
of items that need to be kept in registers from 3 (i, p, q) to 2 (p and
q-p) and requires only one increment around the loop. Strength reduction
and induction variable elimination definitely head this way.
--
J. Eliot B. Moss, Associate Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.