Re: intermediate representation

In article <9102210223.AA15327@cyan.cs.rochester.edu> han@cs.rochester.edu writes:
>(Does the RTL that GCC uses count as one such IR?)


I guess it does.


> Actually, my fellow students and I have taken a look at the RTL dump
>produced by GCC. To our surprise, the RTL dump showed strong dependency
>on the target machine even at the earliest stage of optimization.


This is not the fault of the RTL language, but rather that of the front end.
The front end uses different intermediate code generation strategies,
depending on available instructions and/or big-endianness etc. For example,
If your target machine does not have a multiply instruction, it is reasonable
for the front end to emit code which calls the multiply function.
Now at least you can profit from optimization code which reduces function call
cost. (On the other hand, you might argue, that information is lost, and
may cause problem, say, when trying to perform strength reduction and the
like. - RTL adds a tag to such function calls, explaining waht the function
does:


(call_insn 15 14 16 (parallel[
                      (set (reg:SI 1) ; assign to register 1
                              (call (mem:SI (reg:SI 35)); the return value of this
                                      (const_int 0))) ; function call
                      (use (reg:SI 1))
              ] ) -1 (nil)
      (nil))


(insn 16 15 17 (set (reg:SI 36) ; copy the the return value
              (reg:SI 1)) -1 (nil) ; to register 36
      (expr_list:REG_EQUAL (mult:SI (reg/v:SI 32)
                      (mem:SI (reg:SI 33)))
              (insn_list:REG_RETVAL 10 (nil))))


- The REG_EQUAL says that reg:SI 36 really contains the value computed
by multiplying registers 32 and 33. )


>The RTL dump on SPARC looked very different from that on Sun3 workstation.
>We had expected that the machine dependency would show up at much later
>stage and that we would be able to try optimization with RTL without worrying
>about machine dependencies.


I wouldn't worry too much about machine dependencies. The worst case is
(I guess) that some optimizations do not benefit certain architectures.
But this is probably due to the target processor's peculiarities. Condition
code optimization for example can _never_ benefit a CPU without
condition codes - so what?


>So, my second question is: Is it generally expected for an intermediate
>representation to be machine dependent? How far toward the end of code
>generation phase can machine dependencies be prevented from showing up?


Probably depends on how you define machine dependency and the kind of IR.
In RTL, the language itself is nearly completely machine independent
(except when it comes to things like little/big endianness, which
would be difficult to change after optimizations depending on this
have been performed.) The code emitted, however, depends very much
on the target processor - postincrement language elements, for example,
are never used for targets without postincrement addressing modes. The
sooner you introduce machine dependencies, the sooner you can optimize
aggressively. On the other hand, the language itself should be
as machine independent as possible, to allow easy retargeting.




bye,
mike


Michael K. Gschwind, Dept. for VLSI Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at
mike@vlsivie.uucp
e182202@awituw01.bitnet
Voice: (++43).1.58801 8144
Fax: (++43).1.569697
--

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