Re: testsuite run-time test for sse2 support

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Uros Bizjak wrote:
> Hello!
>
>   
> > The attached patch adds a run-time check for
> > SSE2 support.  I think I picked an instruction
> > that only shows up at >= SSE2.  At this point,
> > I didn't see any need to test for each level
> > individually.
> >     
>
>
>   
> > +# Return 1 if the target supports executing MMX instructions, 0
> > +# otherwise.  Cache the result.
> >     
>
> This comment is wrong, the procedure checks if target supports
> executing SSE2 instructions, and the result is not cached. This
> procedure is however called only once, at the beginning of vectorizer
> testsuite, so it doesn't need to be cached.
>
>   
Grr.. cut and paste.
> +proc check_sse2_hw_available { } {
> +    return [check_runtime x86_sse2_hw_available {
> +       int
> +       main (void)
> +       {
> +         asm volatile ("paddq  %xmm0,%xmm0");
> +         return 0;
> +       }
> +    } "-msse2"]
> +}
> +
>
> The code that checks for SSE2 feature should use CPUID instruction
> through __get_cpuid() call from cpuid.h instead of trapping on unknown
> insn, something similar to what is implemented in
> testsuite/gcc.target/i386/sse2-check.h.
>   

I hacked on that test program to get the attached
program.  I ran it multiple times on qemu.

ext=0x0 sig=0x756e6547
0x781abfd YES on SSE2

I ran the same program natively and got this:

ext=0x0 sig=0x756e6547
0xbfebfbff YES on SSE2

I wonder if qemu is just reporting things wrong. :(
I searched the qemu manual and googled some but
didn't see anything that jumped out.

Does this look like qemu reporting a bogus cpuid or
gcc not parsing it correctly?

> However, since all runtime tests in gcc.target/i386 directory are
> protected by the check using CPUID, it looks that these checks are not
> effective on your target for some reason. Since your target doesn't
> support CPUID, this should be detected by __get_cpuid_max() from
> cpuid.h that follows Intel recommended procedure. Can you check if
> __get_cpuid_max () from gcc/config/i386/cpuid.h returns 0 for your
> target? And if not, why not ;)
>
>   
Since this is qemu, the why not is in the source if we can
(or someone on the list) can grok it.

http://cvs.savannah.nongnu.org/viewvc/*checkout*/qemu/target-i386/helper.c?revision=1.102&root=qemu

has the routine which generates the value but it references
some "env" structure that I don't know how it got initialized.

> BTW: Looking at the rtems testresults, I belive that *-*-rtems* should
> be added to check_profiling_available dg procedure in
> testsuite/lib/target-support.exp. This will remove _lots_ of failures
> from your testresults.
>   
Thank you.  That should help separate the wheat from the
chafe.  I don't really believe there are 100s of real failures
The RTEMS part of the equation isn't as important a test issue
as the CPU part of it.  I am sure there are issues but way fewer
than these general harness/environment ones.

--joel

> Uros.
>   
--joel
#include <stdio.h>
#include <stdlib.h>

#include "cpuid.h"

static void sse2_test (void);

int
main ()
{
  unsigned int eax, ebx, ecx, edx;
  unsigned int ext, sig;

  ext = 0;
  __get_cpuid_max( ext, &sig );
  printf( "ext=0x%x sig=0x%x\n", ext, sig );

  if (!__get_cpuid (1, &eax, &ebx, &ecx, &edx)) {
    printf( "__get_cpuid returned 0\n" );
    return 0;
  }

  /* Run SSE2 test only if host has SSE2 support.  */
  if (edx & bit_SSE2)
    printf( "0x%x YES on SSE2\n", edx );
  else
    printf( "0x%x NO on SSE2\n", edx );

  return 0;
}