Re: rearranging code invalidates liveness info

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
|> The problem I've run into is that this organization seems to make code
|> reorganization for optimization purposes quite difficult, since anything
|> but the most trivial rearrangements will invalidate the annotations on the
|> code. I'm sure this problem must have been encountered by many of you
|> before. How do compiler writers usually handle this problem?


I think the standard approach is to throw away all annotations after
each code transformation. You only build the annotations you need for
a specific transformation (i.e., useless code elimination needs some
kind of use-def chains, but perhaps not your scope or binding info).
Clever arrangement of your optimization passes will allow you to share
some annotations between transformations, but not many.


My approach is to have my IR contain only opcodes & use-def chains.
When I transform the code, I actually transform my use-def chains.
For some global/batch optimizations I need def-use chains; I throw
them away after the transformation. Def-use chains are really cheap
to build if you have use-def chains.


There are folks who do incremental analysis and edits, but they jump
though hoops to preserve their analysis info. And there are times
when a transformation to the code CANNOT be mapped into a transformation
of your annotations, the required information is simply not available
(a conservative mapping can always be had, but not a precise one).


I think the answer here is to carefully engineer your analysis phases
to run as fast as possible. Then invoke the analyses you need for any
particular transformation just prior to the transformation.


Cliff


--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--

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