|rearranging code invalidates liveness info email@example.com.OZ.AU (1994-06-10)|
|Re: rearranging code invalidates liveness info firstname.lastname@example.org (1994-06-13)|
|Re: rearranging code invalidates liveness info email@example.com (1994-06-13)|
|rearranging code invalidates liveness info firstname.lastname@example.org (1994-06-13)|
|Re: rearranging code invalidates liveness info email@example.com (1994-06-13)|
|Re: rearranging code invalidates liveness info firstname.lastname@example.org (1994-06-15)|
|Re: rearranging code invalidates liveness info email@example.com (1994-06-16)|
|Re: rearranging code invalidates liveness info firstname.lastname@example.org (1994-06-16)|
|Re: rearranging code invalidates liveness info email@example.com (1994-06-21)|
|Date:||Wed, 15 Jun 1994 16:28:13 GMT|
Fergus Henderson <firstname.lastname@example.org.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.
Return to the
Search the comp.compilers archives again.