|INTERMEDIATE CODE DESIGN firstname.lastname@example.org (1995-06-24)|
|Intermediate code design email@example.com (David Stone 5887) (1998-01-05)|
|Re: Intermediate code design firstname.lastname@example.org (1998-01-06)|
|Re: Intermediate code design email@example.com (David Chase) (1998-01-06)|
|Re: Intermediate code design firstname.lastname@example.org (Charles Fiterman) (1998-01-08)|
|Re: Intermediate code design email@example.com (Christian von Roques) (1998-01-08)|
|From:||David Chase <firstname.lastname@example.org>|
|Date:||6 Jan 1998 22:41:26 -0500|
|Organization:||Natural Bridge LLC|
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
> Any pointers to articles or books would be very welcome.
There's some pointers to papers at
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, email@example.com
Return to the
Search the comp.compilers archives again.