|IR Representation email@example.com (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-04)|
|Re: IR Representation firstname.lastname@example.org (2015-09-05)|
|Re: IR Representation email@example.com (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-07)|
|Re: IR Representation firstname.lastname@example.org (2015-09-08)|
|Re: IR Representation email@example.com (George Neuner) (2015-09-08)|
|Re: IR Representation firstname.lastname@example.org (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-11)|
|Re: IR Representation DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2015-09-12)|
|Date:||Mon, 7 Sep 2015 23:05:29 -0300|
|Keywords:||optimize, design, comment|
|Posted-Date:||07 Sep 2015 23:24:33 EDT|
Hi Anton, thank you for the answer.
On Sat, Sep 5, 2015 at 1:51 PM, Anton Ertl
> =?UTF-8?B?Q8Opc2Fy?= <email@example.com> writes:
> >- I believe that a linear sequence of instructions would be easier to
> >optimize/analyze, right?
> What kind of linear representation do you have in mind? And what
This linear representation is really just an array of IR instructions,
something on these lines: vector<Instruction*>; As operands
instructions have pointers to entries in the symbol table.
As for optimizations I was planning to start with common sub. expr.
elimination, dead code elimination, loop-invariant code motion, etc.
and later on move to more complex optimizations. I agree with you
that if I have the instructions stored in a stack it would be easy to
do. However, my initial understanding of linear was really an array of
instructions... and from that to construct a tree it seemed a little
complex, it seems like trying to reconstruct an AST from an assembly
stream of instructions.
> >Besides, I have a question about storing the IR as a tree. Should I
> >(a) create an individual tree for each expression/statement in the
> >source or (b) should I create a single tree concatenating the trees
> >for each expression?
> Whatever suits your purpose. My students often create a tree for the
> whole program, but for the task I give them I recommend doing just a
> tree for each simple statement, because the tree-parsing instruction
> selection that they use is not useful for combining tree nodes at a
> higher level (AST nodes for function definitions and such); so when
> they have a tree for the whole program, they just have to write
> tree-parsing rules for all these nodes without any benefit from
I did not understand how can you represent the program using just a
single tree, because sometimes the computations are just
independent... What would be the a single tree for these programs:
a = b;
c = a + 1;
d = a * c;
e = a + a;
or this one:
a = b + c;
d = e + f;
In my current implementation I represent both examples as set of trees
> You can also have data-flow graphs for whole basic blocks or more (but
> that's not directly derived from the abstract syntax tree like my
> students are using). If you want to go in that direction, I recommend
> reading Marc Brandis' thesis:
I think it's better if I come up with something simpler working first.
This seems to be a really good text. I'll read it. Thank you for the
[You make it one tree by inventing a node type for a statement sequence,
either an N-ary one, or a bunch of (statement, next node) pairs. As
he said, it's largely a matter of programming preference. -John]
Return to the
Search the comp.compilers archives again.