[llvm-commits] [PATCH] Adding the TSVC loop benchmarks to the test suite

[Douglas do Couto Teixeira]

Another issue was that the output of the benchmarks in Polybench was
too big, so we had to use hashed output.

Douglas

On Thu, Sep 27, 2012 at 2:05 PM, Douglas do Couto Teixeira
<douglasdocouto at gmail.com> wrote:
> We didn't have any problems with 'inf' IIRC, only with NaNs. The
> problem we had, as Tobias said, was that OS X printed 'nan' and Linux
> printed '-nan' at the same places. Tobias looked it up and found that
> the way NaNs are printed is implementation defined.
>
> Regards,
>
> Douglas
>
> On Thu, Sep 27, 2012 at 1:51 PM, Tobias Grosser <tobias at grosser.es> wrote:
>> On 09/27/2012 05:21 PM, Hal Finkel wrote:
>>>
>>> On Thu, 27 Sep 2012 09:34:11 +0200
>>> Tobias Grosser <tobias at grosser.es> wrote:
>>>
>>>> On 09/27/2012 03:44 AM, Hal Finkel wrote:
>>>>>
>>>>> Please review the attached patch which adds the TSVC loop
>>>>> benchmarks to the LLVM test suite. These are the benchmarks
>>>>> associated with the paper: Maleki, S., et al. An Evaluation of
>>>>> Vectorizing Compilers. PACT'11.
>>>>
>>>>
>>>> Nice.
>>>>
>>>>> I have adjusted each stage so that the double-precision version
>>>>> takes approximately 5 seconds to run on my machine (the float
>>>>> version should be faster, but is not always -- one of the reasons
>>>>> it will be good have this added). With 18 classes each with double
>>>>> and float variants, and assuming that the time for the native
>>>>> binary is comparable to the test binary, the entire benchmark
>>>>> should take approximately 360 seconds to run. Is that too long?
>>>>
>>>>
>>>> I believe that is fine. If they run a lot shorter, the timings will
>>>> be very unstable.
>>>>
>>>>> Do I need to do anything special with the fcmp tolerances?
>>>>
>>>>
>>>> When adding the polybench test cases, the only problem I have seen
>>>> was that NaNs caused problems with textual comparisons as it is
>>>> written differently on OS X and Linux. So better ensure your programs
>>>> don't output NaNs.
>>>
>>>
>>> One of the tests does produce an 'inf' -- was that the same on both
>>> systems, or is that also a problem?
>>
>>
>> I don't recall any problems, but I don't think I tested it. The issue with
>> NaN was that the printf implementation was printing a different string for
>> this. 'NaN' and 'nan' or something like this. If you have a OS X machine,
>> you can probably test it easily.
>>
>> Cheers
>> Tobi