testsuite run-time test for sse2 support

[Uros Bizjak]

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.