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

Douglas do Couto Teixeira douglasdocouto at gmail.com
Thu Sep 27 10:05:14 PDT 2012


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



More information about the llvm-commits mailing list