pd-zexy compilation improvements

[Reinhard Tartler]

On Mon, Aug 23, 2010 at 09:35:24 (CEST), IOhannes m zmoelnig wrote:

> On 2010-08-22 20:06, Jonas Smedegaard wrote:
>> 
>> We should simply suppress the sse flag on 32bit x86, in my opinion.
>> 
>> Or if it really hurts, we should either a) offer to variants or b)
>> convince upstream to implement support for both and detect at runtime if
>> optimized code whould be used or not.
>> 
>> I notice that upstream intend to switch to autotools for next release. 
>> Perhaps you could convince upstream to add an option to add e.g. a
>> --no-optimize or --no-buildtime-featuredetect flag so we can ensure
>> compatibility generally for the archs we target - or if not too much to
>> ask then above described runtime detection?
>
>
> i thought it was there, but cannot find it anymore :-) (probably it's in
> some other lib of mine)
>
> as things stand now, pd-zexy has no runtime cpu-detection support, so
> the best bet is to completely disable the SSE2 code.

For now, I agree that would be best. There are some workarounds for
that, though.

> for future refernce i would like to ask (and i'm aware, that this is not
> the perfect place to ask such a question):
>
> the relevant flags are "-mfpmath=sse -msse" which do 2 things:
> - set some macros to allow the user add handcrafted sse-code
> - use sse optimization
>
> now #1 is clearly a problem, if the program is forced to use handwritten
> sse code (including sse instructions) if there is no sse unit available.
> this can be fixed with runtime checks.
>
> my question is more about the other possibility:
> #2 makes gcc emit sse-instructions; does anybody know whether it also
> automatically provides fallbacks for generic 486 instructions?
> or is any code compiled with "-mfpmath=sse -msse" known (or likely) to
> be incompatible with non-sse cpus?

No, gcc doesn't support this (yet [1]).

But *if* all code that is using SSE is implemented as shared libraries
(i.e., .so files and loaded via ld-linux.so, I didn't check that though)
then you could compile and install different flavors of the library, one
time with and one time without SSE instructions. The dynamic loader will
then at runtime query the kernel for installed harware capabilities and
load the "best" flavor on demand. See the libavcodec52 package as an
example.


[1] You might want to google on 'gcc binutils multiarch' for details; it
is a rather new development with an unfortunate naming, since it clashes
with debian's "multiarch" project which is related but with different
aims.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4