Issues in IR Design

. source language and target language

. porting cost or reuse of existing design

. whether appropriate for optimizations

. U-code IR used on PA-RISC and Mips. Suitable for expression evaluation on stacks but less suited for load- store architectures

. both compilers translate U-code to another form

- HP translates to very low level representation

- Mips translates to MIR and translates back to U-code for code generator

IR design is very much dependent on both the source language and the target language. There are many factors while choosing an intermediate language such as porting cost and reuse of existing design i.e., whether is it economical to reuse the existing design or rather redo from scratch. Here, portability mainly refers to machine-independence, rather than source-language independence. Also, will the IR be appropriate for the optimizations needed. Complexity of the compiler: reuse of legacy compiler parts, compilation cost, multiple vs. one IR levels (as mentioned, a compiler may use several IRs from different levels, or a single IR featuring several levels), and compiler maintenance. To emphasize the latter claim, here are two examples of implementation of optimization in the MIPS and the PA-RISC. Don't give too much attention to the examples as of now. Just try to get a hang of what's being said.

1. MIPS The problem introduced was how to optimize the front-end generated representation, namely UCODE Stack Based IR (a language that was something like an old instance of Java Byte-Code, which served as a target language for many front-ends). Given that the translation from UCODE to machine code ("load"/"store" based architecture) was already written, and since the required optimization used a higher-level representation, what was finally implemented is as follows: Ironically, this solution translates into a higher-level representation, performs the required optimizations, and then translates back to the low- level representation, from which the machine code is generated. Note, however, that we assume here that translation from one representation to another is accurate (but not necessarily efficient).

2. PA-RISC The second example shows a similar design for PA-RISC (developed by HP), but such that is using a lower-level IR (SLLIC) for optimization and doesn't translate back to UCODE. This is schematically represented as follows: