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 <ja...@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 <echri...@gmail.com> wrote: > >> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits < >> cfe-commits@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 <dblai...@gmail.com> wrote: >>> >>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits < >>>> cfe-commits@lists.llvm.org> wrote: >>>> >>>>> On 1 December 2015 at 17:23, James Molloy via cfe-commits >>>>> <cfe-commits@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@lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>>>> >>>> _______________________________________________ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >>
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits