Re: Intermediate code design

David Stone 5887 wrote:


> (1) Updating operations.


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


It depends. Generally, I would say yes, especially if you intend
to optimize the code.


> (2) Function calls, especially pure function calls


> If a function does not have side effects, then it seems to me that
> there is no need for dataflow analysis to give up when it finds a
> function call, and so it would help if the design of the intermediate
> code facilitated dataflow analysis over function calls.


It's possible, but I'm not sure that you'd get sufficient bang for
your buck here. Again, it depends. If your triples are at a low
level, then there's no such thing as a "pure function" because
registers will be trashed, etc.


> One scheme which, I think, would work is:
>
> destination 1st operand operation 2nd operand
>
> arglist = make_empty [no operands]
> arglist = arglist append arg1
> arglist = arglist append arg2
> ...
> retval = functionname apply arglist
>
> Here all the above operations can be treated like simple arithmetic
> operations for the purpose of dataflow analysis.


True, except that if I say "x + y, where x = 3 and y = 4" then
I can turn it into "7". Your "arithmetic" doesn't generalize
in any useful way.


> However, I have not read of this approach anywhere: is there some
> hidden snag, or is there a better approach?


I think this happens pretty often, but people don't do much with
it.


> Any pointers to articles or books would be very welcome.


There's some pointers to papers at


http://softlib.rice.edu/MSCP/iloc.html


Don't read just one -- the original and the revised versions
are a good deal different, and the reasons why are some of the
things that you might want to know.


--
David Chase, chase@world.std.com
--

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