Re: rearranging code invalidates liveness info

mernst@research.microsoft.com
Wed, 15 Jun 1994 16:28:13 GMT

          From comp.compilers

Related articles
rearranging code invalidates liveness info fjh@munta.cs.mu.OZ.AU (1994-06-10)
Re: rearranging code invalidates liveness info preston@noel.cs.rice.edu (1994-06-13)
Re: rearranging code invalidates liveness info cliffc@noel.cs.rice.edu (1994-06-13)
rearranging code invalidates liveness info ssimmons@convex.com (1994-06-13)
Re: rearranging code invalidates liveness info newburn@aslan.ece.cmu.edu (1994-06-13)
Re: rearranging code invalidates liveness info mernst@research.microsoft.com (1994-06-15)
Re: rearranging code invalidates liveness info hbaker@netcom.com (1994-06-16)
Re: rearranging code invalidates liveness info cliffc@noel.cs.rice.edu (1994-06-16)
Re: rearranging code invalidates liveness info daniel@quilty.stanford.edu (1994-06-21)
| List of all articles for this month |

Newsgroups: comp.compilers
From: mernst@research.microsoft.com
Keywords: optimize
Organization: Compilers Central
References: 94-06-070
Date: Wed, 15 Jun 1994 16:28:13 GMT

Fergus Henderson <fjh@munta.cs.mu.OZ.AU> asks:
> anything but the most trivial rearrangements will invalidate the annotations
> on the code. ... How do compiler writers usually handle this problem?


As others have pointed out, the traditional approaches are to either rerun
all analyses after each transformation or to run analyses immediately
before they are needed. At the other end of the spectrum (requiring much
more work and potentially saving more effort) is incremental maintenance of
semantic information, either directly or by rerunning analyses over a small
affected region in which the semantic information has been invalidated.


In our project we run analyses just before their results are required, but
we also maintain global information about which analyses are valid, so that
they are not needlessly recomputed. Each transformation specifies which
semantic information it maintains and which it invalidates.


This approach was extremely easy to implement, and the transformation
writer is not forced to mark any analyses as maintained; in the default
case, all analyses are marked as invalid. The runtime cost is also
negligible. (Unfortunately, I don't have any hard data about how much work
this approach saves.) While it can't always do as well as the more
complicated schemes, it was a reasonable and easy compromise to make.


-Michael Ernst
mernst@research.microsoft.com


--


Post a followup to this message

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