[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] clarification [was Re: illegal instruction again]
From: |
graydon hoare |
Subject: |
[Monotone-devel] clarification [was Re: illegal instruction again] |
Date: |
Sun, 11 Apr 2004 16:19:09 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040208) |
Robert Bihlmeyer wrote:
Seconded. My preferences are:
1. run-time detection [tricky]
2. --with-msse2=(yes|no|auto) where auto guesses from
the environment, and no is the default [easy]
3. don't optimise [trivial]
4. guess from the environment by default [easy]
yes, I know we must do runtime detection. there is some confusion here,
I suppose I'm not being sufficiently clear about the situation. here is
what's going on:
- there is only one file, cryptopp/integer.cpp, which I want
to use sse2 code
- there is only one function in there I want to use sse2 code
- that function is wrapped in runtime sse2 detection logic
- the detection logic uses the CPUID instruction, which is reliable
- there was never a version of the code without runtime detection
- the runtime detection code works
- the include test checked to see if the compiler could
generate the sse2 code using intrinsics. not all compilers
know about the instruction patterns or intrinsic functions
necessary. if you try to compile intrinsic functions on a compiler
which doesn't know about them (eg. gcc 3.0) it crashes. so we need
to check that.
- the include test had nothing to do with whether the sse2
code was going to be enabled at runtime, only whether to bother
asking the compiler to compille it. if it can't understand the
instructions, the whole block of code should be elided by #ifdef,
rather than crashing the compiler
- if you do not pass -msse2 on the compile line, the compiler does
not know how to generate the sse2 code. it is "dumbed down".
- therefore to generate the code at all, when it's possible (on a
smart enough compiler), we need to pass -msse2.
- detecting whether to pass -msse2 is all our configury test did
- that test works. the presence of emmintrin.h does reliably signal
that the current compiler can compile sse2 instructions.
that's for the code written to explicitly use sse2 instructions, in the
file cryptopp/integer.cpp, guarded by runtime checks. the problem we're
running into is not related to that code. that stuff seems to be ok.
the problem we're running into is related to files and functions *other*
than the specially guarded function inside cryptopp/integer.cpp. it
seems that passing -msse2 on the compiler command line causes
*spontaneous and unchecked* sse2 code to be emitted, elsewhere. the
compiler thinks it's free to generate all the sse2 code it likes,
willy-nilly. so it generates it anywhere it sees the opportunity. for
example, as johnathan matthew pointed out 3 days ago, it generates sse2
instructions to perform trivial integer <-> double casts (totally
standard ansi C) inside the lua interpreter. this is not cool. we can't
disable these instructions at runtime.
for the time being I've just turned the whole mess off. I'll revisit
later. the obvious (and awful) way around this is to isolate the two
function variants in separate compilation units and switch between them
at runtime (rather than switching within a single compilation unit), but
this will require more reorganization.
-graydon