Re: Working with RTL

>I have asked R. Stallman about [emitting and rereading RTL] and the answer he
>gave is essentially "Using and Porting GNU CC" V2.4 Sec. 14.18, where
>he states
>
>"People frequently have the idea of using RTL stored as text in a file as
>an interface between a language front end and the bulk of GNU CC. This
>idea is not feasible."


    As one of the co-developers of the RTL notation that gcc's RTL notation
was derived from (Chris Fraser being the other) and the kernel of the code
used in gcc to perform instruction selection (combine.c), I can assure you
that it is possible to emit RTLs and read them back in for processing. It
may not be feasible in gcc, but we and others do this all the time with
vpo, an optimizer developed at the University of Virginia that has the
same ancestor as gcc (PO which was developed at U. of Arizona). It is
incredibly handy. Let me tell you about some of the ways this feature is
used.


    One simple, but handy use, is to spit out the RTLs after some
processing, edit them by hand (for example, changing register
assignments), and then reading them back in and examining the emitted
code. This technique is helpful for debugging the optimizer as well as
trying new transformations (code improvements) and seeing what the effect
down the road is. An automated version of this technique can be used to
prototype other transformations such as inlining, loop unrolling, loop
interchange, etc.


    Another use of this feature is to spit out RTLs for one machine,
translate them to RTLs for another, then optimize them for the target
machine. This is handy for binary-to-binary translation. At least one
company uses this technique in a commercial product. This also works for
optimizing existing assembly code.


    Another use is to retarget different front ends. The lcc front end has
been bolted to vpo by having lcc emit RTLs to a file, and then vpo reads
them in, optimizes and spits out assembly language.


    You get the idea.


    One thing you sacrifice up by allowing this is compilation speed. Our
measurements indicate this capability adds about 5% (our RTLs are tightly
encoded, if they weren't the cost would be higher) to compilation time. We
believe the flexibility is worth the cost.


Cheers,
Jack Davidson
E-mail: jwd@virginia.edu
--

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