Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 10:41 AM, Sylvain Pion
<sylvain.p...@sophia.inria.fr> wrote:
Richard Guenther wrote:
The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR. Would exposing
that to C/C++ be of any help? For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS such that proper rounding to the nearest integer
value is performed).
Off the top of my head, I don't see anything both really useful
and not-surprising in C/C++ here, but I may well miss something.
There are some C++0x features, axiom and constexpr, which are
related to this area. It's not clear yet to me how all this
will interact, but I have good hope to see some connections
there (like modeling some associativity rules with axioms).
Note that axioms do not change the behaviour of a program -- assuming
the program contains `no bugs'.
I don't mean to change the behavior of a program without changing
its code. But you can change its code so that it describes whether
a particular function can support associativity transformations.
(then it's up to the compiler to realize what the axiom is about,
but that's another story : you can imagine a simple, non-general
implementation, recognizing standard axioms as "built-ins",
and trigger the corresponding -fassociative-math on the functions
which are constrained by this concept+axiom)
One way I could imagine to have axioms and associativity rules
on FP interact in a program would be to write a wrapper type,
say std::associative<double>, which would just wrap and forward
the operations to double, but which would, in addition, have
a concept_map for a concept whose axioms would specify the
associativity rules. Then, if you call a function which
you know is OK if the compiler does the associativity
transformations, you can just call it with std::associative<double>
arguments.
Other ways might be possible. E.g. avoiding the wrapping if
the associativity concept/axiom is somehow local to the function
and does not leak elsewhere if you provide an Associativity
concept_map for double (or are "scoped concept maps" about
this issue ? I should learn about this.).
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
