search for: altivecful

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent:

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

Hello, I'm using Mono with experimental LLVM backend support on PowerPC. I noticed that although LLVM's IR contains SIMD instructions the assembly produced doesn't contain any Altivec instructions and my PowerPC970 machine of course has Altivec support. Isn't there some kind of autodetection? I searched in Target sources but only found out that Altivec is disabled by default. Can

On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Thursday, January 31, 2013 9:26:15 AM > > Subject: [LLVMdev] Getting command line options to affect subtarget features > > > > The problem I'm trying to

On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > To: llvmdev at cs.uiuc.edu > > > Sent: Thursday, January 31, 2013 9:26:15 AM > > > Subject: [LLVMdev] Getting command line

Hello, I'm using Mono with experimental LLVM backend support on PowerPC. I noticed that although LLVM's IR contains SIMD instructions the assembly produced doesn't contain any Altivec instructions and my PowerPC970 machine of course has Altivec support. Isn't there some kind of autodetection? I searched in Target sources but only found out that Altivec is disabled by default. Can

I saw some mail go by a bit ago about doubles-vs-floats, but I seem to have lost it. I'm interested in rewriting the mdct code using Altivec on MacOS X. Altivec doesn't support doubles, though -- the only floating point vector type is single precision floats. Vorbis currently has doubles everywhere -- is this really necessary? Doubles are supposedly faster than floats in the PPC

...l take a look at it. At the time, I thought I wanted control logic that was impossible in C, but that may not be the case. It didn't occur to me that Linux and Apple would use different assemblers; elsewhere Apple uses the GNU tools. I'm also a bit surprised that people are using flac on an Altivecful Linux/PPC system (but I did attempt for such a system to fall back to the non-altivec C code). End digression. Can you point me to a good reference on altivec.h? -- Brady Patterson (brady@spaceship.com) RLRR LRLL RLLR LRRL RRLR LLRL

...s 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. > I'm also a bit surprised that people are using flac on an Altivecful > Linux/PPC > system (but I did attempt for such a system to fall back to the > non-altivec C > code). End digression. I think all of that works, it's just the different assembler syntaxes causing problems. > Can you point me to a good reference on altivec.h? http://developer....

Hey guys, I just released my new MacOSX-based OpenAL implementation...part of it is a Ogg Vorbis decoder based on the 1.0 reference libraries. I spent some time optimizing them and found that many of the hotspots in libvorbis are perfect candidates for vectorization, so I wrote Altivec versions of them. The end result? Decoding of a .ogg file is between 30 and 50% faster on a Mac with an

Sorry that it has been a while since the last altivec patch. I have noticed something interesting, and so it remains unfinished... On the ppc, even with the altivec optimizations, almost a quarter of the time is spent in FLAC__stream_encoder_process(). I finally discovered that it is because of all the integer to float conversions. Aside from being exceptionally slow on the g4, they

The problem I'm trying to solve: Invoking clang on PowerPC with -fno-altivec has no effect. >From what I've been able to piece together, PPC.td specifies various CPUs and the processor features available on each. So for example we have: def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",

Josh Coalson wrote: > --- Luca Barbato <lu_zero@gentoo.org> wrote: > >>Josh Coalson wrote: >> >>>since I don't know how to resolve this, in current CVS I have >>>checked in a system where there are src/libFLAC/ppc/as and >>>src/libFLAC/ppc/gas selected by configure. I have also checked >>>in as many patches as I could make sense of

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

Hi, This patch adds Altivec-optimized implementations of oc_enc_frag_sad and oc_enc_frag_ssd. This patch is against the latest svn revision of theora-ptalarbvorm. Speeds up encode on a plant stop-motion clip on a 1 GHz PPC 7447 by ~3%, timewise. Time spent in oc_enc_frag_sad is reduced from 4.2% to 2.3% and oc_enc_frag_ssd from 1.2% to 1.0%, as reported by Shark. Currently this is only

Hi, I have been playing with Altivec, and I rewrote a couple of the routines in assembly. Looking at the archives, I noticed that there may already be some effort on this. Anyways... Right now, I have two routines working. They need to be cleaned up, made relocatable, and documented; otherwise, they seem to work fairly well. I see an overall ~27% speed improvement when encoding with the

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:

Besides SPE (FSL e500v? cores) there are other powerpc processors that don't support altivec instructions so only enable them when it's 100% sure that the target has it. Signed-off-by: Gustavo Zacarias <gustavo at zacarias.com.ar> --- src/libFLAC/Makefile.am | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/libFLAC/Makefile.am b/src/libFLAC/Makefile.am index

Erik de Castro Lopo wrote: >> > I'll try to power up my Linux/PPC machine in the next couple of days >> > so I can test this. >> >> Any news? > > Sorry, haven't had a chance to set up that machine. Hopefully this > weekend. I have several patches, but they interfere with this ppc/altivec patch. (one of them changes lpc.h,another changes

----- Original Message ----- > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, January 31, 2013 9:26:15 AM > Subject: [LLVMdev] Getting command line options to affect subtarget features > > The problem I'm trying to solve: Invoking clang on PowerPC with > -fno-altivec has no effect. > > From what