r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

Eric Christopher via cfe-commits cfe-commits at lists.llvm.org
Tue Dec 1 11:12:15 PST 2015


Could you provide an example proving this? I answered your question with
exactly how to split it up.

On Tue, Dec 1, 2015, 10:54 AM James Molloy <james at jamesmolloy.co.uk> wrote:

> You cannot test the intrinsic emission with the same quality when
> splitting the test in two. You miss testing the producer consumer
> relationship between the two components.
>
> I'm sorry that this use case appears to you as not qualifying.
> On Tue, 1 Dec 2015 at 18:45, Eric Christopher <echristo at gmail.com> wrote:
>
>> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> > That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> End to end tests have significant disadvantages as we all know. However
>>> they do have some advantages too( that I have already enumerated) and the
>>> question currently as I see it is how do we best get/keep those advantages
>>> in our testing strategy?
>>>
>>> W.r.t the test-suite, that is a possibility. There are currently no
>>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>>> can see why not. The disadvantage there for me is that we take short
>>> running, simple tests and demote them to be run less often.
>>>
>>> Would it make sense to have a dedicated subdirectory in clang/test for
>>> these kind of tests, so they can be directly enumerated and therefore kept
>>> to a minimum , yet be allowed when they add value?
>>>
>>>
>> There are a few cases where we can't currently test something, but none
>> of the cases you or Renato have brought up qualify. I'm curious what you'd
>> put in this directory?
>>
>> -eric
>>
>>
>>> James
>>> On Tue, 1 Dec 2015 at 18:29, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>>> cfe-commits at lists.llvm.org> wrote:
>>>>
>>>>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>>>> <cfe-commits at lists.llvm.org> wrote:
>>>>> > This isn't just a NEON intrinsics thing, and this isn't just an
>>>>> ARM/AArch64
>>>>> > thing. There needs to be some way to test the compiler from start to
>>>>> finish.
>>>>> > Not being able to do so leaves serious coverage holes.
>>>>>
>>>>> Just for the sake of completeness, a hole that the test-suite doesn't
>>>>> cover.
>>>>>
>>>>
>>>> Are they things the test-suite couldn't (either technically or
>>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>>> could do so?
>>>>
>>>>
>>>>>
>>>>>
>>>>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100%
>>>>> must
>>>>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
>>>>> in the
>>>>> > compiler output.
>>>>>
>>>>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>>>>> tests, ELF section placement, FP contracts, Debug info, Inline
>>>>> assembly, Unicode support, object creation, library symbol clashes,
>>>>> back-end diagnostics are some of the examples that need to go all the
>>>>> way to asm or object code.
>>>>>
>>>>>
>>>>> > If you can describe a way to get the same strength of testing without
>>>>> > running the backend during clang tests, I'm all ears!
>>>>>
>>>>> I'm particularly interested in how do we keep the IR printed in the
>>>>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>>>>> change, to guarantee that Clang changes don't generate silent codegen
>>>>> faults down the line in LLVM and vice-versa.
>>>>>
>>>>
>>>> That would sort of defeat the point of having the testing and projects
>>>> separated though - it would tie the tests together and produce most of the
>>>> undesirable outcomes of having single end-to-end tests.
>>>>
>>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>>> developer would have a test to run where they would not if the test
>>>> remained in Clang only)
>>>>
>>>>
>>>>>
>>>>> cheers,
>>>>> --renato
>>>>
>>>>
>>>>> _______________________________________________
>>>>> cfe-commits mailing list
>>>>> cfe-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>>
>>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151201/5004cd7b/attachment-0001.html>


More information about the cfe-commits mailing list