This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch for merging graphite branch (before tuplification)
- From: Roberto Bagnara <bagnara at cs dot unipr dot it>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Mark Mitchell <mark at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, David Edelsohn <edelsohn at gmail dot com>, "Harle, Christophe" <christophe dot harle at amd dot com>, Tobias Grosser <grosser at fim dot uni-passau dot de>, Konrad Trifunovic <konrad dot trifunovic at gmail dot com>, Albert Cohen <Albert dot Cohen at inria dot fr>, "The Parma Polyhedra Library developers' list" <ppl-devel at cs dot unipr dot it>
- Date: Fri, 08 Aug 2008 17:06:11 +0200
- Subject: Re: patch for merging graphite branch (before tuplification)
- References: <cb9d34b20807251914jb7fb76q4452be18461d7464@mail.gmail.com> <84fc9c000807260228h12552595x17b2a7556d35913b@mail.gmail.com> <cb9d34b20808021726w3dcb5015o9b256ef393dba02c@mail.gmail.com> <Pine.LNX.4.64.0808031809020.15922@digraph.polyomino.org.uk> <84fc9c000808031220t14f60e5bie1760eaaa413aeb5@mail.gmail.com> <Pine.LNX.4.64.0808031925260.15922@digraph.polyomino.org.uk> <84fc9c000808031320m153160b0l60db9d80b1f58742@mail.gmail.com> <Pine.LNX.4.64.0808032051010.15922@digraph.polyomino.org.uk>
Joseph S. Myers wrote:
On Sun, 3 Aug 2008, Richard Guenther wrote:
Sure. But modulo bugs there shouldn't be a difference in code-generation
(for the PPL part at least), as it provides "basic math" like mpfr. Code
generation could be affected by the version of Cloog though.
Thanks - this is useful information. If PPL's interface is such that
there is a unique correct output for any inputs, like MPFR, then indeed we
only need check the version is recent enough rather than requiring an
exact version.
Dear All,
I think a little clarification is necessary. It is not strictly true
that the PPL's interface is such that there is a unique correct output
for any input. Let us start from generic convex polyhedra, which (as
far as I can tell) is the only numerical abstraction used by cloog.
There the point is that, given a convex polyhedron, there are many
minimal constraint systems (i.e., not containing any redundant constraint)
that describe it. No polyhedra library that I know uses strong normalization
methods for constraints (like the Gram-Schmidt orthogonalization process)
since they are costly and tend to produce very big coefficients.
So the most that can be guaranteed is a minimal form (i.e., with
the minimum number of individually-normalized constraints),
but there is no guarantee to obtain, for the same polyhedron,
the same set of constraints. However, if you stick to a particular
PPL release, you can count on obtaining the same set of constraints
on all architectures.
Other numerical abstractions implemented by the PPL, such as octagonal
shapes, bounded-difference shapes and boxes using floating point coefficients,
give rise to results that are not exactly reproducible. The only guarantee
that the PPL provides is correctness; due to the nature of floating point
computations any change of PPL version, compiler version, architecture,
math library and so forth may give rise to different (but always correct)
results.
Finally, the mixed integer programming solver integrated in the PPL
optionally use floating point computations in order to implement the
steepest-edge heuristics: in the presence of multiple optima you can
get one or another depending on all that influences the execution
of floating point computations.
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it