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
