|constant folding at parse time email@example.com (1992-08-17)|
|Re: constant folding at parse time firstname.lastname@example.org (1992-08-17)|
|Re: constant folding at parse time email@example.com.EDU (Tim Pierce) (1992-08-19)|
|Re: constant folding at parse time firstname.lastname@example.org (1992-08-20)|
|Re: constant folding at parse time email@example.com (1992-08-21)|
|Re: constant folding at parse time firstname.lastname@example.org (1992-08-21)|
|Re: constant folding at parse time email@example.com (1992-08-24)|
|constant folding vs exceptions firstname.lastname@example.org (1992-08-26)|
|From:||email@example.com (Willem Jan Withagen)|
|Date:||Fri, 21 Aug 1992 08:44:59 GMT|
|Keywords:||parse, optimize, comment|
=> example. But what about an expression such as "4 + y + 4"? As I see it,
=> a shift-reduce parser following the rule
=> expr -> expr + expr
=> | CONST
=> | ID
And John says:
=> [The only approach I've seen is pretty much brute force -- when you have a
=> subtree with multiple instances of an associative operator, flatten the
=> tree into a list, sort the list to put all the constants together,
=> collapse the constants, and remake a tree. It is my dim recollection that
=> the Ritchie PDP-11 compiler actually did this, because you can get
=> significant savings in some kinds of addressing expressions. -John]
Now I don't want to open another tarpit again, but this certainly is going
to have effects on the semantics of the used program. When it is only
applied to address calculation which comes from arrays, ... then the user
would not always have to find out. But what about:
y := maxint-1;
...... (nothing for y)
x := maxint-y+10;
This might or might not give the correct results.
And it gets even more tricky when the user has used ()'s to make shure that
thing were done in the proper order.
- Do we then annotate the intermediate code that it should not be
- Or do we only reorganise when we can show that there is no
And how do we show this?
- what about Floating point stuff?
PS: In the compiler I'm doing I've decided to put an IM->IM
cse-eliminator (as attribute evaluator) which can be applied
whenever on the IM-tree.
These questions arise from the fact that I think that agresive
actions could do more harm than that they are worth.
Digital Information Systems Group, Room EH 10.35
Eindhoven University of Technology
P.O. 513 Tel: +31-40-473401,Fax: +31-40-448375
5600 MB Eindhoven The Netherlands
[This was for integer expressions in C, which traditionally haven't paid
much attention to overflows. You're right, though, particularly for floating
point expressions users will not appreciate arbitrary rearragement. -John]
Return to the
Search the comp.compilers archives again.