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

[Eric Christopher via cfe-commits]

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/07ca2455/attachment-0001.html>