monotone-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]