On 1 December 2015 at 10:42, James Molloy via cfe-commits
wrote:
> 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, sim
On 1 December 2015 at 19:53, James Molloy wrote:
> I think I'd be OK with demoting these tests to the test-suite, and dealing
> with the slightly lower amount of testing that comes with it if it means we
> can keep the clang tests in a nice shape.
If the tests are independent of sub-architecture
On 1 December 2015 at 19:45, David Blaikie wrote:
> These cases I don't understand - if they're features LLVM supports we'd just
> test them straight up. If you run our test suite against another compiler it
> should tell you if it's compatible with our compiler (does it offer the same
> functiona
Ok, understood.
I think I'd be OK with demoting these tests to the test-suite, and dealing
with the slightly lower amount of testing that comes with it if it means we
can keep the clang tests in a nice shape.
We'd need to ensure there were equivalent tests written that test only
clang produced IR
On 1 December 2015 at 19:42, James Molloy wrote:
> Why do you think it would be non trivial? Some simple lit tests aren't
> exactly arduous on most targets.
I mean having more points in the testing matrix.
Clang check-all is cheaper than running the test-suite, but if we
start moving more tests
On Tue, Dec 1, 2015 at 11:39 AM, Renato Golin
wrote:
> On 1 December 2015 at 19:09, David Blaikie wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this
Hi Renato,
> by a non-trivial amount.
Why do you think it would be non trivial? Some simple lit tests aren't
exactly arduous on most targets.
James
On Tue, 1 Dec 2015 at 19:39, Renato Golin wrote:
> On 1 December 2015 at 19:09, David Blaikie wrote:
> > Not sure I follow - I'm not suggesting a
On 1 December 2015 at 19:09, David Blaikie wrote:
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of
On Tue, Dec 1, 2015 at 10:45 AM Eric Christopher 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 togeth
Hi,
FWIW, I'm happy with moving these tests into the test-suite. They do make
sense to be expressed in a compiler-neutral manner, even though some may
test clang-specific behaviour.
There is a UnitTests directory already, and adding the ability to run LIT
tests should be simple within the new CMa
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 wrote:
> You cannot test the intrinsic emission with the same quality when
> splitting the test in two. You miss testing the producer consumer
> relatio
On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin
wrote:
> On 1 December 2015 at 18:29, David Blaikie wrote:
> > 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?
>
> IMO, it's a philosoph
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 wrote:
> On Tu
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
On 1 December 2015 at 18:29, David Blaikie wrote:
> 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?
IMO, it's a philosophical issue. The test-suite is a whole-program
execution, and all tha
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
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
> 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 th
On Tue, Dec 1, 2015 at 9:23 AM James Molloy wrote:
> Hi Eric,
>
> 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.
>
> Unit testing is
On 1 December 2015 at 17:23, James Molloy via cfe-commits
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
Hi Eric,
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.
Unit testing is great, but integration testing is required sometimes to
ensure m
Hi James,
I disagree with you completely on every point except that you need to write
new tests.
There is absolutely, as I said in the thread where I noticed this for the
x86 intrinsics, that you cannot supply this test up and test it in the
front and the back end separately. If you believe this
On 1 December 2015 at 11:44, James Molloy via cfe-commits
wrote:
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> th
Hi Eric,
While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR int
Hi,
This is entirely the wrong way to do these tests. They shouldn't depend on
assembly output or optimization. Please split them onto frontend IR tests
and backend assembly tests.
Thanks!
On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
Author: alelab01
Date: Sun Nov 29 04:53:28 2015
New Revision: 254251
URL: http://llvm.org/viewvc/llvm-project?rev=254251&view=rev
Log:
ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
Add/Subtract.
Add missing tests that accidentally were not committed in rL254250.
Differen
25 matches
Mail list logo
