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

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 11:39 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 1 December 2015 at 19:09, David Blaikie <dblaikie at gmail.com> 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 testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>

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 functionality), so we don't have to maintain a distinction
between functionality we support and other compilers support, and
functionality we support and no other compiler support.

If the test isn't testing observable functionality, but some implementation
detail, that's a separate question and one I'd probably say shouldn't go in
the test-suite.


> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>

If you say so :)

- Dave


>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151201/5993db30/attachment.html>