[llvm-dev] [test-suite] making polybench/symm succeed with "-Ofast" and "-ffp-contract=on"

[Renato Golin via llvm-dev]

On 11 October 2016 at 12:15, Sebastian Pop <sebpop.llvm at gmail.com> wrote:
>>  1. Only test the non-FP-contracted output
>
> Yes, this is what I'm doing.

If the whole test is about testing multiplications, what's the point of this?


>>  2. Run the FP-contracted test only for a very small size (so that we'll stay within some reasonable tolerance of the reference output)
>>  3. Change the matrix to something that will make the test numerically stable (it does not look like the matrix itself matters to the performance; where do the values come from?).

3 is more sound, 2 may be more practical.


> -      C_StrictFP[i][j] = C[i][j] = ((DATA_TYPE) i*j) / ni;
> -      B[i][j] = ((DATA_TYPE) i*j) / ni;
> +      C_StrictFP[i][j] = C[i][j] = ((DATA_TYPE) i-j) / ni;
> +      B[i][j] = ((DATA_TYPE) i-j) / ni;
>      }
>    for (i = 0; i < nj; i++)
>      for (j = 0; j < nj; j++)
> -      A[i][j] = ((DATA_TYPE) i*j) / ni;
> +      A[i][j] = ((DATA_TYPE) i-j) / ni;

Changing from multiplication to subtraction changes completely the
nature of the test and goes towards "return 0;", ie, fiddling with the
code so that the compiler "behaves" better. This is *not* a solution.

Hal,

For large scale numerical programs, if fp-contract can result in large
scale differences, we need to think about this approach by default.

If the loop above cannot be contained in an 1e-8 range for double
values over a large dataset, than I guess the transformation is going
a bit too far.

If not, we should be able to come up with a reasonable tolerance that
makes the test still be relevant.

cheers,
--renato