search for: _supported

Hi i tested acls with some clients horde/imp mulberry thunderbird squirrelmail kmail and i couldnt get it run proberly i have no problems testing setacl etc with plain telnet session, and i have no error in verbose logging but it looks like acl is only working partly with some clients so show acls is working mostly but setting only partly horde/imp and mulberry dont show any acls any idea? --

...at fixed point numbers must not be optimized as integers - eg if two saturated fixed point constants would overflow in an addition operation, the result should as well be saturated. Doing this in a series of steps with intrinsics would be quite ridiculous as far as performance goes, because this is _supported by the DSP in hardware_ in a single instruction :-) What about perhaps introducing a new type, and allowing just minor extensions, while barring it from more heavy scattered code? I mean, the GVN pass works by just adding an enum entry and a switch case for each new instruction. But in other case...

...not be optimized > as integers - eg if two saturated fixed point constants would overflow in > an addition operation, the result should as > well be saturated. Doing this in a series of steps with intrinsics would > be quite ridiculous as far as performance goes, > because this is _supported by the DSP in hardware_ in a single instruction > :-) Isn't it better to add instructions for saturated and/or fixed point arithmetic? ... At least that would be consistent with the design of having separate instructions for signed and unsigned add etc. - Morten

Erik de Castro Lopo wrote: > Yes, I think src/libFLAC/include/private/cpu.h would be a better place > for this SSE version support stuff. > > Would you be able to do it or should I? OK, the attached patch adds FLAC__SSE*_SUPPORTED and also moves their definitions to cpu.h. It also adds GCC 4.9 support (http://gcc.gnu.org/gcc-4.9/changes.html: "It is now possible to call x86 intrinsics from select functions in a file that are tagged with the corresponding target attribute without having to compile the entire file with th...

...ized as integers - eg if > > two saturated fixed point constants would overflow in an addition > > operation, the result should as well be saturated. Doing this in a > > series of steps with intrinsics would be quite ridiculous as far as > > performance goes, because this is _supported by the DSP in hardware_ > > in a single instruction :-) > > > > What about perhaps introducing a new type, and allowing just minor > > extensions, while barring it from more heavy scattered code? I mean, > > the GVN pass works by just adding an enum entry and a switc...

...rs must not be optimized as integers - eg if > two saturated fixed point constants would overflow in an addition > operation, the result should as well be saturated. Doing this in a > series of steps with intrinsics would be quite ridiculous as far as > performance goes, because this is _supported by the DSP in hardware_ > in a single instruction :-) > > What about perhaps introducing a new type, and allowing just minor > extensions, while barring it from more heavy scattered code? I mean, > the GVN pass works by just adding an enum entry and a switch case for > each new...

...gers - eg if >>> two saturated fixed point constants would overflow in an addition >>> operation, the result should as well be saturated. Doing this in a >>> series of steps with intrinsics would be quite ridiculous as far as >>> performance goes, because this is _supported by the DSP in hardware_ >>> in a single instruction :-) >>> >>> What about perhaps introducing a new type, and allowing just minor >>> extensions, while barring it from more heavy scattered code? I mean, >>> the GVN pass works by just adding an enum en...

...sation" = "xyes" ; then XIPH_ADD_CFLAGS([-msse2]) fi Also it's not possible to enable SSE4.1 intrinsic functions even with -msse4.1 option. The patch fixes both problems. --------------- BTW: I'm not sure that share/compat.h is the best place to define these FLAC__SSEN_SUPPORTED macros. Maybe it's better to move them to some libFLAC .h file? E.g. to src/libFLAC/include/private/cpu.h? -------------- next part -------------- A non-text attachment was scrubbed... Name: sse_support.patch Type: application/octet-stream Size: 10488 bytes Desc: not available Url : http://list...

...t;>> two saturated fixed point constants would overflow in an addition > >>> operation, the result should as well be saturated. Doing this in a > >>> series of steps with intrinsics would be quite ridiculous as far as > >>> performance goes, because this is _supported by the DSP in hardware_ > >>> in a single instruction :-) > >>> > >>> What about perhaps introducing a new type, and allowing just minor > >>> extensions, while barring it from more heavy scattered code? I mean, > >>> the GVN pass works...