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

[James Molloy via cfe-commits]

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?

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151201/0bf9868c/attachment.html>