pd-zexy compilation improvements

[IOhannes m zmoelnig]

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 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?


fmasdr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100823/a00fdb93/attachment.bin>