Re: constant folding at parse time

buehlman@iwf.mabp.ethz.ch (Buehlmann Thomas)
Fri, 21 Aug 1992 11:51:46 GMT

          From comp.compilers

Related articles
Re: Simple constant folding in bison parser drw@kronecker.mit.edu (1992-08-10)
constant folding at parse time wjw@eb.ele.tue.nl (1992-08-17)
Re: constant folding at parse time markh@csd4.csd.uwm.edu (1992-08-17)
Re: constant folding at parse time twpierce@amhux1.amherst.EDU (Tim Pierce) (1992-08-19)
Re: constant folding at parse time scott@bbx.basis.com (1992-08-20)
Re: constant folding at parse time wjw@eb.ele.tue.nl (1992-08-21)
Re: constant folding at parse time buehlman@iwf.mabp.ethz.ch (1992-08-21)
Re: constant folding at parse time drw@euclid.mit.edu (1992-08-24)
| List of all articles for this month |

Newsgroups: comp.compilers
From: buehlman@iwf.mabp.ethz.ch (Buehlmann Thomas)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 21 Aug 1992 11:51:46 GMT
References: 92-08-040 92-08-114
Keywords: parse, attribute

twpierce@amhux1.amherst.EDU (Tim Pierce) writes:


>The discussion about constant folding has intrigued me a little bit, and
>I've been a little stumped figuring out how I would implement this in the
>general case. Writing code into mknode() to fold the addition or
>multiplication of two nodes with constant value makes sense to me, for
>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


Watch out, this optimization may be inherently unsafe since you change the
semantical meaning between the optimized version and the non-optimized
version in such a way that different results may be produced. Just two
short examples:


1) x/12 * 12
You may reduce this to x, but what happens, if x is not divisible by 12?
In this case you obviously got a clash between the mathematical meaning of
the expression and the 'procedural' meaning the programmer wanted to
achieve.


2) assume the maximal size of int be 16!
12 + x + 5
depending on x and the implementation you might get different results,
maybe even the compiler complains while folding the constants. However the
writer might have known that x is always strictly less than -1!
--


Post a followup to this message

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