Re: testsuite run-time test for sse2 support

[Uros Bizjak <ubizjak at gmail dot com>]

Joel Sherrill wrote:

> > >  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 am now printing the return value from __get_cpuid_max()
>
>
> ext=0x0 sig=0x756e6547 returned=0x2
> 0x781abfd YES on SSE2
>
> Isn't the "sig" supposed to be >= 0x80000000?

No, it says "uneG" in Intel speak, as in "_Genu_ine Intel"

> > >  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?
> > >     
> >
> > This all depends on the return value of __get_cpuid_max(). It returns
> > max value of base cpuid level (5 in my case), and shoould return 0 if
> > cpuid is not supported. This follows the procedure outlined in
> > http://download.intel.com/design/processor/applnots/24161832.pdf,
> > section 2: "Detecting the CPUID Instruction".
> >
> >   
> I added a print before the return on !__get_cpuid and it is returning 
> non zero.

So, this is qemu bug. It advertises CPUID support with %eax=2, and when 
queried with cpuid, it returns SSE2 support. Either SSE2 should be fully 
fixed in quemu, or it should stop advertising SSE2 (and other levels) 
support.

> > It is true, that this is not the most maintained code on the planet,
> > so some bitrot is possible. The return value of __get_cpuid_max() on
> > your target will tell...
> >
> >   
> The call to __get_cpuid is checking against level 1 and this is a level 2.

This is cpuid level, not SSE level. We want cpuid information indexed 
with %eax=1.

Uros.