How to not fold constants?

How to not fold constants?

[Stephen L Moshier]

IEEE awareness rules in C9X require that floating point constant
expressions sometimes get folded and sometimes not.  For example, if
the expression occurs in executable code, it might not be folded; but
if it is a static initializer it would be folded.

It looks like c-parse.c makes up a tree containing the constant
expression and passes that tree to fold-const.c, without any indication
of the context where the expression came from in the source program.
Other functions also call fold-const.c and maybe they are not aware
of the context either.  The question is, how can fold-const.c figure
out whether the expression is a static initializer or is executable code?

Re: How to not fold constants?

[Toon Moene]

Stephen L Moshier wrote:

> IEEE awareness rules in C9X require that floating point constant
> expressions sometimes get folded and sometimes not.  For example, if
> the expression occurs in executable code, it might not be folded; but
                                               ^^^^^ ^^^
"might not" or "shall not" ?

> if it is a static initializer it would be folded.
                                   ^^^^^
"would" or "shall" ?

> It looks like c-parse.c makes up a tree containing the constant
> expression and passes that tree to fold-const.c, without any indication
> of the context where the expression came from in the source program.
> Other functions also call fold-const.c and maybe they are not aware
> of the context either.  The question is, how can fold-const.c figure
> out whether the expression is a static initializer or is executable code?

I think an easier (and more obvious IMHO) solution is to have the C
frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
static initializer and build(...) otherwise [or is there a snag in there
that I'm overlooking ?]

More serious is the problem of constant propagation.  I do not know
off-hand how much cprop gcc does these days, but with it, the following
code:

	p = 0.1;
	... /* no intervening assignments to p */
	for (i = 0; i < n; i++)
		a[i] = 10.0 * p * b[i];

could be turned into:

	for (i = 0; i < n; i++)
		a[i] = one * b[i];

where `one' is the constant one gets when letting the compiler combine
0.1 * 10.0 instead of letting it happen at run time ["what's the
difference ?" I hear from the audience.  The difference is that the
rounding mode (away from or towards zero or up or down) might be
different at compile time than at run time, giving you a different
`one'].

It's not clear from your mail what the C9X standard requires here, but
for consistency's sake I would say that it also has to prohibit this
"constant folding".

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: How to not fold constants?

[Joern Rennecke]

> I think an easier (and more obvious IMHO) solution is to have the C
> frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
> static initializer and build(...) otherwise [or is there a snag in there
> that I'm overlooking ?]

Yes.  There might be integer expressions inside that we want to fold.
We also want to fold floating point if this can be done without an
inexact operation or generating NaNs.

Re: How to not fold constants?

[Toon Moene]

Joern Rennecke wrote:

> > I think an easier (and more obvious IMHO) solution is to have the C
> > frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
> > static initializer and build(...) otherwise [or is there a snag in there
> > that I'm overlooking ?]

> Yes.  There might be integer expressions inside that we want to fold.

Is that true - shouldn't the *frontend* decide how to interpret mixed
mode expressions ?  Or is fold-const.c so tied up with C that the
Fortran frontend probably shouldn't use it ?!?

> We also want to fold floating point if this can be done without an
> inexact operation or generating NaNs.

The challenge is to determine that the outcome after folding has a
single correct result, independent of the rounding mode (round to
nearest, round to zero, round up or round down - note, I got the first
one wrong in my original message) applied to the constituent numerical
operations.  This condition is necessary, because the compiler cannot
know what the rounding mode _is_, at run time [Off-hand, I'd think that
trying to determine this is equivalent to the halting problem].

Seems like quite a challenge - I wouldn't be surprised if there weren't
_that_ many expressions for which this holds.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

PS: wish you a sunny eclipse :-)

Float constant propagation

[Stephen L Moshier]

>       p = 0.1;
>       ... /* no intervening assignments to p */
>       for (i = 0; i < n; i++)
>               a[i] = 10.0 * p * b[i];
>
>could be turned into:
>
>       for (i = 0; i < n; i++)
>               a[i] = one * b[i];

I did not know this was happening.  It is an unpleasant surprise to
see that change across a statement boundary.  It is just plain
anti-social behavior on the part of the compiler.  I think it should
be rooted out and put under fast-math.

Re: How to not fold constants?

[Stephen L Moshier]

> It's not clear from your mail what the C9X standard requires

The C9X rule says, roughly speaking, that float constant expressions
may be folded only if nothing can possibly go wrong.  It goes on to
say that not ever folding at all is an acceptable way to implement
that rule  -- except for the case of static initializations.

So I am asking, how do we figure out that an expression is a
static initializer?

Re: How to not fold constants?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9908102002570.16852-100000@moshier.ne.mediaone.net >
you write:
  > 
  > > It's not clear from your mail what the C9X standard requires
  > 
  > The C9X rule says, roughly speaking, that float constant expressions
  > may be folded only if nothing can possibly go wrong.  It goes on to
  > say that not ever folding at all is an acceptable way to implement
  > that rule  -- except for the case of static initializations.
  > 
  > So I am asking, how do we figure out that an expression is a
  > static initializer?
I'm not aware of any such way off the top of my head.  You may need to create
one, probably by extending "fold" to accept and pass through an argument
which indicates that you're trying to fold an initializer.  Then change the
callers in an appropriate manner.

jeff

Re: How to not fold constants?

[Jeffrey A Law]

  In message < 37B0A847.B4EC8D0A@moene.indiv.nluug.nl >you write:
  > > Yes.  There might be integer expressions inside that we want to fold.
  > 
  > Is that true - shouldn't the *frontend* decide how to interpret mixed
  > mode expressions ?  Or is fold-const.c so tied up with C that the
  > Fortran frontend probably shouldn't use it ?!?
fold-const.c is supposed to be generic enough to be used by any front end.  If
we need to extend the tree structures to indicate when certain folds are safe
vs not safe, then that's the way to deal with these problems.

Similarly for the folding routines found in cse & combine; they are supposed to
be language independent.

jeff

Re: How to not fold constants?

[Geoff Keating]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < 37B0A847.B4EC8D0A@moene.indiv.nluug.nl >you write:
>   > > Yes.  There might be integer expressions inside that we want to fold.
>   > 
>   > Is that true - shouldn't the *frontend* decide how to interpret mixed
>   > mode expressions ?  Or is fold-const.c so tied up with C that the
>   > Fortran frontend probably shouldn't use it ?!?
> fold-const.c is supposed to be generic enough to be used by any front end.  If
> we need to extend the tree structures to indicate when certain folds are safe
> vs not safe, then that's the way to deal with these problems.
> 
> Similarly for the folding routines found in cse & combine; they are supposed to
> be language independent.

cse (& combine?) will need to be changed at a higher level; if you have

#pragma STDC FENV_ACCESS ON
void foo(void);
double bar(double x)
{
  double y;
  y = x + x;
  foo(void);
  y += x + x;
  return y;
}

you must still perform three '+' operations, despite the common
subexpression, because foo() may change the rounding mode or test
the exception flags (the addition may overflow, for instance).


-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: How to not fold constants?

[Jeffrey A Law]

  In message < m33dxq7uku.fsf@gluttony.geoffk.wattle.id.au >you write:
  > cse (& combine?) will need to be changed at a higher level; if you have
No, this does not mean we need to change cse/combine at a higher level.  Just
that we have to expose to the compiler that a call insn can have more
side effects than a call has now.

That does not require any kind of high level conceptual changes.

jeff

Re: How to not fold constants?

[Jeffrey A Law]

  In message < 37B0A847.B4EC8D0A@moene.indiv.nluug.nl >you write:
  > > Yes.  There might be integer expressions inside that we want to fold.
  > 
  > Is that true - shouldn't the *frontend* decide how to interpret mixed
  > mode expressions ?  Or is fold-const.c so tied up with C that the
  > Fortran frontend probably shouldn't use it ?!?
fold-const.c is supposed to be generic enough to be used by any front end.  If
we need to extend the tree structures to indicate when certain folds are safe
vs not safe, then that's the way to deal with these problems.

Similarly for the folding routines found in cse & combine; they are supposed to
be language independent.

jeff

Re: How to not fold constants?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9908102002570.16852-100000@moshier.ne.mediaone.net >
you write:
  > 
  > > It's not clear from your mail what the C9X standard requires
  > 
  > The C9X rule says, roughly speaking, that float constant expressions
  > may be folded only if nothing can possibly go wrong.  It goes on to
  > say that not ever folding at all is an acceptable way to implement
  > that rule  -- except for the case of static initializations.
  > 
  > So I am asking, how do we figure out that an expression is a
  > static initializer?
I'm not aware of any such way off the top of my head.  You may need to create
one, probably by extending "fold" to accept and pass through an argument
which indicates that you're trying to fold an initializer.  Then change the
callers in an appropriate manner.

jeff

Float constant propagation

[Stephen L Moshier]

>       p = 0.1;
>       ... /* no intervening assignments to p */
>       for (i = 0; i < n; i++)
>               a[i] = 10.0 * p * b[i];
>
>could be turned into:
>
>       for (i = 0; i < n; i++)
>               a[i] = one * b[i];

I did not know this was happening.  It is an unpleasant surprise to
see that change across a statement boundary.  It is just plain
anti-social behavior on the part of the compiler.  I think it should
be rooted out and put under fast-math.

Re: How to not fold constants?

[Joern Rennecke]

> I think an easier (and more obvious IMHO) solution is to have the C
> frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
> static initializer and build(...) otherwise [or is there a snag in there
> that I'm overlooking ?]

Yes.  There might be integer expressions inside that we want to fold.
We also want to fold floating point if this can be done without an
inexact operation or generating NaNs.

Re: How to not fold constants?

[Geoff Keating]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < 37B0A847.B4EC8D0A@moene.indiv.nluug.nl >you write:
>   > > Yes.  There might be integer expressions inside that we want to fold.
>   > 
>   > Is that true - shouldn't the *frontend* decide how to interpret mixed
>   > mode expressions ?  Or is fold-const.c so tied up with C that the
>   > Fortran frontend probably shouldn't use it ?!?
> fold-const.c is supposed to be generic enough to be used by any front end.  If
> we need to extend the tree structures to indicate when certain folds are safe
> vs not safe, then that's the way to deal with these problems.
> 
> Similarly for the folding routines found in cse & combine; they are supposed to
> be language independent.

cse (& combine?) will need to be changed at a higher level; if you have

#pragma STDC FENV_ACCESS ON
void foo(void);
double bar(double x)
{
  double y;
  y = x + x;
  foo(void);
  y += x + x;
  return y;
}

you must still perform three '+' operations, despite the common
subexpression, because foo() may change the rounding mode or test
the exception flags (the addition may overflow, for instance).


-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: How to not fold constants?

[Jeffrey A Law]

  In message < m33dxq7uku.fsf@gluttony.geoffk.wattle.id.au >you write:
  > cse (& combine?) will need to be changed at a higher level; if you have
No, this does not mean we need to change cse/combine at a higher level.  Just
that we have to expose to the compiler that a call insn can have more
side effects than a call has now.

That does not require any kind of high level conceptual changes.

jeff

Re: How to not fold constants?

[Toon Moene]

Stephen L Moshier wrote:

> IEEE awareness rules in C9X require that floating point constant
> expressions sometimes get folded and sometimes not.  For example, if
> the expression occurs in executable code, it might not be folded; but
                                               ^^^^^ ^^^
"might not" or "shall not" ?

> if it is a static initializer it would be folded.
                                   ^^^^^
"would" or "shall" ?

> It looks like c-parse.c makes up a tree containing the constant
> expression and passes that tree to fold-const.c, without any indication
> of the context where the expression came from in the source program.
> Other functions also call fold-const.c and maybe they are not aware
> of the context either.  The question is, how can fold-const.c figure
> out whether the expression is a static initializer or is executable code?

I think an easier (and more obvious IMHO) solution is to have the C
frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
static initializer and build(...) otherwise [or is there a snag in there
that I'm overlooking ?]

More serious is the problem of constant propagation.  I do not know
off-hand how much cprop gcc does these days, but with it, the following
code:

	p = 0.1;
	... /* no intervening assignments to p */
	for (i = 0; i < n; i++)
		a[i] = 10.0 * p * b[i];

could be turned into:

	for (i = 0; i < n; i++)
		a[i] = one * b[i];

where `one' is the constant one gets when letting the compiler combine
0.1 * 10.0 instead of letting it happen at run time ["what's the
difference ?" I hear from the audience.  The difference is that the
rounding mode (away from or towards zero or up or down) might be
different at compile time than at run time, giving you a different
`one'].

It's not clear from your mail what the C9X standard requires here, but
for consistency's sake I would say that it also has to prohibit this
"constant folding".

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: How to not fold constants?

[Stephen L Moshier]

> It's not clear from your mail what the C9X standard requires

The C9X rule says, roughly speaking, that float constant expressions
may be folded only if nothing can possibly go wrong.  It goes on to
say that not ever folding at all is an acceptable way to implement
that rule  -- except for the case of static initializations.

So I am asking, how do we figure out that an expression is a
static initializer?

How to not fold constants?

[Stephen L Moshier]

IEEE awareness rules in C9X require that floating point constant
expressions sometimes get folded and sometimes not.  For example, if
the expression occurs in executable code, it might not be folded; but
if it is a static initializer it would be folded.

It looks like c-parse.c makes up a tree containing the constant
expression and passes that tree to fold-const.c, without any indication
of the context where the expression came from in the source program.
Other functions also call fold-const.c and maybe they are not aware
of the context either.  The question is, how can fold-const.c figure
out whether the expression is a static initializer or is executable code?

Re: How to not fold constants?

[Toon Moene]

Joern Rennecke wrote:

> > I think an easier (and more obvious IMHO) solution is to have the C
> > frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a
> > static initializer and build(...) otherwise [or is there a snag in there
> > that I'm overlooking ?]

> Yes.  There might be integer expressions inside that we want to fold.

Is that true - shouldn't the *frontend* decide how to interpret mixed
mode expressions ?  Or is fold-const.c so tied up with C that the
Fortran frontend probably shouldn't use it ?!?

> We also want to fold floating point if this can be done without an
> inexact operation or generating NaNs.

The challenge is to determine that the outcome after folding has a
single correct result, independent of the rounding mode (round to
nearest, round to zero, round up or round down - note, I got the first
one wrong in my original message) applied to the constituent numerical
operations.  This condition is necessary, because the compiler cannot
know what the rounding mode _is_, at run time [Off-hand, I'd think that
trying to determine this is equivalent to the halting problem].

Seems like quite a challenge - I wouldn't be surprised if there weren't
_that_ many expressions for which this holds.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

PS: wish you a sunny eclipse :-)