Erik de Castro Lopo wrote:>> There's the following code in stream_decoder.c: > > Like you, I don't see a lot of value in these. I think I'll decline > these.FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec: why libFLAC compares 'order' and 8 in C code and not in asm.
Miroslav Lichvar
2014-Jul-03 12:52 UTC
[flac-dev] [PATCH] two patches of doubtful usefulness
On Thu, Jul 03, 2014 at 04:21:59PM +0400, lvqcl wrote:> Erik de Castro Lopo wrote: > > >> There's the following code in stream_decoder.c: > > > > Like you, I don't see a lot of value in these. I think I'll decline > > these. > > FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 > and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. > > I wonder why the same wasn't done for PPC/Altivec: why libFLAC compares > 'order' and 8 in C code and not in asm.Perhaps because it's easier to do it in C than in asm? :) Wrapping the check in #ifdef will save few instructions on non-ppc archs, but in this case I think it doesn't really matter. It would make the code less readable and more likely someone will forgot about it in the future and break it for ppc. -- Miroslav Lichvar
lvqcl wrote:> FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 > and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. > > I wonder why the same wasn't done for PPC/Altivec: why libFLAC compares > 'order' and 8 in C code and not in asm....more about PPC ASM: http://git.xiph.org/?p=flac.git;a=commitdiff;h=63d489ae3140296419afdfc4cfc87cc2c7cb9faf http://git.xiph.org/?p=flac.git;a=commitdiff;h=3c8d2973cb87e318c11f3a487f2204bf0d673176 +AM_CONDITIONAL(FLaC__HAS_AS__TEMPORARILY_DISABLED, test "yes" = "no") -if FLaC__HAS_AS +#@@@@@@ +if FLaC__HAS_AS__TEMPORARILY_DISABLED -CPUCFLAGS = -maltivec -mabi=altivec -force_cpusubtype_ALL +#@@@@@@ PPC optimizations temporarily disabled +CPUCFLAGS = -maltivec -mabi=altivec -force_cpusubtype_ALL -DFLAC__NO_ASM Does it mean that PowerPC/Altivec asm optimizations were disabled almost 10 years ago?
Erik de Castro Lopo
2014-Jul-04 11:50 UTC
[flac-dev] PPC asm is disabled since Jan 2005? Why?
lvqcl wrote:> Does it mean that PowerPC/Altivec asm optimizations were disabled > almost 10 years ago?Certainly seems that way. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
lvqcl wrrote:> ...more about PPC ASM: > http://git.xiph.org/?p=flac.git;a=commitdiff;h=63d489ae3140296419afdfc4cfc87cc2c7cb9faf > Does it mean that PowerPC/Altivec asm optimizations were disabled almost 10 years ago?Found the cause: http://lists.xiph.org/pipermail/flac-dev/2005-January/001696.html http://www.mail-archive.com/flac-dev at xiph.org/msg00104.html "Back in October 2004, I did a bit of work on FLAC to get version 1.1.1 to build correctly under GNU/Linux/PPC. Only now have I realised that somewhere along the way something broke in FLAC's decoding. On my machine, roughly 50% of FLAC files are being decoded incorrectly" -- John Steele Scott http://lists.xiph.org/pipermail/flac-dev/2005-January/001718.html "since it is going to take me a while to sort this out, and since we need to get a release out to fix the sonames problem, I have disabled PPC asm functions for now and will get back to it after the release. the static binaries I make for the darwin binary release will have them though, because it's easy for me to compile the right one" -- Josh Coalson I suspect that PPC/Altivec asm code is disabled for good.