Re: Intermediate code design

David Stone (david.stone@cambridge.simoco.com) wrote:
> (1) Updating operations.


> Suppose the source language supports updating operations, for example
> x += y in C.


> Should this become


> x = x + y


depends. If you are not doing GCSE analysis then make up an extra
three-op code for the += operand as it will help you generate better
code. If you ARE doing GCSE then keep the icode as simple as possible,
the GCSE will catch such relationships when they need to be caught.




> destination 1st operand operation 2nd operand


> arglist = make_empty [no operands]
> arglist = arglist append arg1
> arglist = arglist append arg2
> ...
> retval = functionname apply arglist


I wouldn't touch that design myself. It makes much more sense to me
to define a three-op code similar to 'push' and then the argument can
be handled only once as a special type of statement. And the function
call because another simple-twp-op statement, no need to clutter up
the dataflow analysis and the actual code-generate with this type of
special case.


And I think ASU is where I read that the basic problem you are going
to have is if you pass a pointer to a function. If this happens you
do NOT need to stop the global dataflow analysis, but to be safe you
DO have to mark anything the pointer can possibly point to as changed
in the same way you would mark things on any normal pointer
assignment. This means to handle a language like C satisfactorily you
almost have to do a dataflow analysis on pointers, or you are going to
have to mark all active variables as changed any time any pointer gets
assigned to or passed to a function. Note I am talking about analysis
which is limited to the scope of a single function; if you are doing
hefty inter-procedural analysis I suppose you could get things even
better but I don't know anything about that.


By the way when you are doing lcse analysis whether you stop at
function calls is highly processor dependent. On cisc architectures
with few registers you are probably going to have to since you are
probably going to allow functions to wipe out all temps. On risc
architectures with lots of registers you could design it to keep a lot
of temps, but, you probably need lots of interprocedural analysis to
be effective in this.


David
--

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