Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!iecc!compilers-sender
From: mike@vlsivie.tuwien.ac.at (Michael K. Gschwind)
Newsgroups: comp.compilers
Subject: Re: intermediate representation
Keywords: optimize, design, analysis
Message-ID: <2342@tuvie.UUCP>
Date: 23 Feb 91 15:40:45 GMT
References: <9102210223.AA15327@cyan.cs.rochester.edu>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: mike@vlsivie.tuwien.ac.at (Michael K. Gschwind)
Organization: Vienna University of Technology, AUSTRIA
Lines: 76
Approved: compilers@iecc.cambridge.ma.us

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
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


Brought to you by Super Global Mega Corp .com