Re: constant folding at parse time

you write:
=> 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
        reorganised?
    - Or do we only reorganise when we can show that there is no
        danger?
        And how do we show this?
    - what about Floating point stuff?


Willem Jan


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
Internet: wjw@eb.ele.tue.nl
X400: C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
[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 comp.compilers page.
Search the comp.compilers archives again.