>In practice everyone uses round to nearest even.
Not when implementing interval arithmetic or affine arithmetic, etc.
--
This space intentionally left blank.
Joe Buck wrote:-
> > I think it's desirable for front-ends to be able to fold floating
> > point constant expressions too, no? It can be handy for diagnostics
> > such as detecting overflow or unreachable code based on conditionals
> > whose expression is a floating one, albeit constant.
>
> The
Joe Buck wrote:
The problem is that the user can independently set the IEEE rounding mode.
This means that you can only fold floating point constants in cases where
the generated result is exact; you cannot fold 1./3. for example.
Also, you should not assume that the user wants the kinds of diagnos
Mark Mitchell wrote:
Yes, that's useful -- but it's not actually *necessary* for a conforming
C++ compiler to be able to fold floating-point constants.
Also, note that strictly speaking, folding floating-point operations usually
violates the IEEE standard, which requires rounding mode to be able t
On Tue, 15 Feb 2005, Joe Buck wrote:
> The problem is that the user can independently set the IEEE rounding mode.
> This means that you can only fold floating point constants in cases where
> the generated result is exact; you cannot fold 1./3. for example.
You can fold 1./3. unless the user uses
On Wed, Feb 16, 2005 at 08:01:13AM +0900, Neil Booth wrote:
> Mark Mitchell wrote:-
>
> > However, while that may be necessary for Java, it's not necessary for
> > C++. In C++, fold should only be called for "integral constant
> > expressions", which, by definition, are made up of simple operat
Neil Booth wrote:
Mark Mitchell wrote:-
However, while that may be necessary for Java, it's not necessary for
C++. In C++, fold should only be called for "integral constant
expressions", which, by definition, are made up of simple operations on
integers. (It's a little more complicated than t
Mark Mitchell wrote:-
> However, while that may be necessary for Java, it's not necessary for
> C++. In C++, fold should only be called for "integral constant
> expressions", which, by definition, are made up of simple operations on
> integers. (It's a little more complicated than that, but a
> "Roger" == Roger Sayle <[EMAIL PROTECTED]> writes:
Roger> The operator BIT_FIELD_REF, for example, can be seen as a
Roger> canonical representation of a shift-and-mask or a
Roger> mask-and-shift operation.
The problem that lead to the creation of the can_use_bit_fields_p lang
hook was that
Roger Sayle writes:
>
> On Tue, 15 Feb 2005, Andrew Haley wrote:
> > There's one other thing to bear in mind when considering the way that
> > fold relates to language front ends. We've seen problems in Java
> > where fold() returned tree nodes that Java didn't recognize: one time,
> > for
On Tue, 15 Feb 2005, Andrew Haley wrote:
> There's one other thing to bear in mind when considering the way that
> fold relates to language front ends. We've seen problems in Java
> where fold() returned tree nodes that Java didn't recognize: one time,
> for example, it returned a BITFIELD_EXPR.
Andrew Haley wrote:
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art in
> C++. (Though that operat
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art in
> C++. (Though that operation would be recursi
Richard Kenner wrote:
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
I think I'm agreeing with you, but I just want to make sure that "need" in
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
I think I'm agreeing with you, but I just want to make sure that "need" in
the above means "requi
I agree with Nathan. I'm going to try to restate.
Premises:
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
2. It is of course useful to share optimization
On Feb 12, 2005, at 15:58, Richard Kenner wrote:
As several front-end people have suggested, calling fold whilst
constructing parse trees shouldn't be necessary (as shown by the
shining examples of g77 and GNAT).
I don't follow. GNAT certainly calls fold for every expression it
makes.
As several front-end people have suggested, calling fold whilst
constructing parse trees shouldn't be necessary (as shown by the
shining examples of g77 and GNAT).
I don't follow. GNAT certainly calls fold for every expression it makes.
In reality, many of the transformations p
On Feb 12, 2005, at 14:57, Nathan Sidwell wrote:
I entirely agree. Unfortunately what we have now is not that --
fold is doing both optimization and (some) C & C++ semantic stuff.
Your proposal to have the tree folders check wether the program
obeys C/C++ languages semantics seems fundamentally fl
Geert Bosch wrote:
Front ends should be responsible for doing any constant folding that
their language definition requires. Otherwise, you'd get the strange
situation that legality of a program depends on the strength of the
optimizers, compilation flags used or even target properties.
I entirely a
On Feb 12, 2005, at 12:57, Nathan Sidwell wrote:
Well, it depends on the FE's language definition :) For C and C++ the
above is not a constant-expression as the language defines it. I can
see a couple of obvious ways to deal with this with an FE specific
constant expression evaluator,
1) during p
Roger,
However, the utility of early fold to the GCC compiler is much greater
than simply compile-time evaluating expressions with constant operands.
One of the reasons that fold is so fast, is that it can rely on the fact
that all of a trees operands have already been folded. In fact, much
of the
Kazu,
Can a compile-time constant appearing in an initializer be as wild as
the following?
0 ? (foo () + 9) : (3 + 5)
Here (foo () + 9) does not fold to a constant, but the whole
expression does fold to 8.
Well, it depends on the FE's language definition :) For C and C++ the
above is not a const
Hi Nathan,
> hm, we may be in violent agreement :) It depends what you mean
> by 'early fold'. You say it would handle constant expressions for FEs
> -- isn't that the same as what I described as a constant expression
> evaluator?
Yes.
> After all, if it is just for constant exprs, it is requi
> I don't know whether these operations should be part of the same SSA
> optimization or not. #2 is more of a constant propagation kind of
> thing I guess. #1 is the kind of thing that has made const-fold so
> complicated. #1 is the important thing to add to the SSA optimizers,
> isn't it?
Yes.
I
On Sat, 12 Feb 2005 06:33:42 -0700 (MST), Roger Sayle
<[EMAIL PROTECTED]> wrote:
>
> On Sat, 12 Feb 2005, Nathan Sidwell wrote:
> > I question if it is better to fold early. As I've said before, I think
> > the optimizations that fold performs should be turned into a proper SSA
> > optimization p
On Sat, 12 Feb 2005, Nathan Sidwell wrote:
> I question if it is better to fold early. As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary.
As for a proper tree-ssa optimizatio
Kazu,
Maybe we can have an early fold and a general fold. The former would
handle constant expressions for front ends. The latter is a full
fledged version but optimized to handle GIMPLE statements.
hm, we may be in violent agreement :) It depends what you mean
by 'early fold'. You say it would
Hi Nathan,
> I question if it is better to fold early. As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary. In the
> front end, folding should not generally be done. I see two
Nathan Sidwell writes:
>
> I question if it is better to fold early. As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary. In the
> front end, folding should not generally
Kazu Hirata wrote:
I am planning to reorganize fold as suggested by Roger Sayle on IRC.
good for you! reorganizing fold is an excellent idea.
The shortest way to describe this mini project would be to develop the
tree equivalent of simplify_gen_ARITY and simplify_ARITY in the RTL
world. Doing so s
On Feb 12, 2005, at 12:06 AM, Kazu Hirata wrote:
Any comments?
I like this change.
-- Pinski
Hi,
I am planning to reorganize fold as suggested by Roger Sayle on IRC.
The shortest way to describe this mini project would be to develop the
tree equivalent of simplify_gen_ARITY and simplify_ARITY in the RTL
world. Doing so should reduce the number of scratch tree nodes
created when idioms l
33 matches
Mail list logo
