475779 - LIR and/or nanojit should do SSE2 detection

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Steven Johnson]

Currently we require th Tamarin embedder to detect SSE2 presence and tell us whether we can use it or not. Since all Tamarin embedders on Windows and Linux-x86 will need this functionality, it should be moved into Tamarin, since the best the embedder can do is get it right, and the worst is to get it wrong (leading to subpar performance or crashes).

Comment 1

[Rob Cameron]

SSE2 detection is an instance of SWAR detection (where SWAR =
SIMD Within a Register).

I am spending some time looking at possible systematic approaches
to dynamic SWAR detection involving that could potentially apply to 
Tamarin as well as other applications and SSE2 as well as other
architectures.   

I am concerned about different projects each doing part of the job
and having a mixed bag of corner cases that don't quite work.   

Note that there is substantial evolution of SWAR support in processors
at the present time, so this problem is becoming increasingly important.

Here are some of my initial notes.

1.  Support for SWAR detection should likely be considered separately
from general SWAR support.   The basic reason is that SWAR detection
is a function that needs to run on a family of processors that share
a common set of generic instructions, but which may differ in whether
SWAR operations are supported or not and what the level of that support is.

For example, the ia32 family may include SWAR support for MMX, SSE, SSE2,
SSE3, SSE4 and so on.   The ppc family may include SWAR support for 
Altivec (=VMX) or not.

The SWAR detector must be able to run successfully on processors within
these families even when the SWAR support is lacking.   Therefore,
it must be encapsulated in a unit that is compiled without any
of the relevant SWAR flags (e.g., -msse2 or -maltivec).

2.  The CPUID instruction can be used on ia32 to query whether a
particular processor supports various features.    However, each
vendor of compatible processors can provide their own specification
and implementation of CPUID.   This adds complexity and creates the
challenge of updating detection logic as processors evolve and
further options become available.

Intel and AMD documentation for CPUID are available here.
http://download.intel.com/design/processor/applnots/24161832.pdf
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf

3.  Processor detection may also be supported by the underlying operating
system.   For example, the following link includes recommendations for
Altivec processor detection under Mac OS X.
http://developer.apple.com/hardwaredrivers/ve/g3_compatibility.html

4.  Another OS issue is whether the SWAR operations are allowed by the OS
or not.   There are cases where it is not, even if the processor is
capable.


5.  Illegal instruction trapping.   Various cases of CPU detection
that you can find out there are based on the method of illegal instruction
trapping.   In essence, try a desired SWAR operation sequence and see
if it excecutes successfully.   If not, capture the SIGILL interrupt
and report that the requested SWAR processing is not available.

Is this a general solution to the problem or should it only be used when
no other methods are known to work?   Can we capture this in a general
bit of logic?  Even if it cannot be used for all cases, it does seem
worth trying to define it in a generic way, so that one common code base
could be used for the cases where it is relevant.

Comment 2

[Brent Baker]

Looks like bug# 500466 depends on this issue and it is currently targeted for the current release.

Comment 3

[Rick Reitmaier]

If nanojit ever evolves to support more interesting SIMD across different architectures then Rob's comment should be revisited, but for now, we're only interested in x86.

Since bug 500466 has been resolved , I'm closing this.

Comment 4

[Brent Baker]

Verified, build system is testing JIT on non-sse2 hardware (windows-p3-deep)