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:20:27 PST 2015


On Tue, Dec 1, 2015 at 10:45 AM 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?
>
>
FWIW to elaborate here on a place I know we can't test well at the moment
is the creation of the TargetMachine itself. This is why I've been trying
to pull as much stuff out of the API call and put it into the IR where
possible. It's a lot of refactoring to keep it particularly clean which is
why it's slow going.

-eric


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


More information about the cfe-commits mailing list