similar to: [LLVMdev] Turning sub-target features on/off (e.g. Altivec on PowerPC)

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

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

I updated the patch to read a call graph from a text file. I tested it with the attached call.txt from lld linking chromium. Unfortunately the resulting lld doesn't seem any faster. One thing I noticed is that the most used symbols seem to be at the end of the file. In any case, can you add tests and send the lld patch for review? Thanks, Rafael On 31 July 2017 at 15:19, Davide Italiano

Hi Dale, > PPC Altivec supports vector type v16i8 (and others) where the element > type is not legal (in llvm's implementation). When we have a > BUILD_VECTOR of these types with constant elements, LegalizeTypes first > promotes the element types to i32, then builds a constant pool entry of > type v16i32. are you sure? I would expect it to build v4i32. Ciao, Duncan.

On Nov 9, 2009, at 6:33 PM, Duncan Sands wrote: > Hi Dale, > >> PPC Altivec supports vector type v16i8 (and others) where the >> element type is not legal (in llvm's implementation). When we have >> a BUILD_VECTOR of these types with constant elements, LegalizeTypes >> first promotes the element types to i32, then builds a constant >> pool entry of

--- Chris Csanady <cc@137.org> wrote: > 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,

OK, checked it all in (only minor modifications: I used the existing FLAC routines for allocating aligned memory). on a side note, I got the Project Builder stuff all working again. still have to figure out how to integrate assembly compilation though. Josh --- Brady Patterson <brady@spaceship.com> wrote: > > Here's what I listed in that email. Merging doesn't appear to

Included is an updated patch against Flac 1.1.1. Although I can not be certain, I believe that it will function under Linux as well as Darwin. By default, the asm versions of the functions are disabled. However, if you are on a Darwin system, you may enable them with: CFLAGS=-DUSE_ASM_ALTIVEC_RESTORE ./configure I have also included support to detect AltiVec and also PPC64 availability,

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

--- John Steele Scott <toojays@toojays.net> wrote: > 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. > > I presume that I

--- 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 (the cpu.c detection > > stuff and the

Luca Barbato <lu_zero@gentoo.org> writes: > Josh Coalson wrote: >>>Probably a version check could help. >> how about this logic: >> if cpu is ppc >> if as exists >> if as is apple version >> use as >> else if as is gnu version >> use as to assemble but src/libFLAC/ppc/gas directory >> else >>

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

This set of patches removes PPC/Altivec code from FLAC. I decided to split the patch into 5 parts to make it more simple: 1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16* from lpc.h and stream_decoder.c 2) removes PPC-specific code from cpu.c and cpu.h 3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk 4) removes as/gas/PPC-specific stuff from configure.ac and

lvqcl wrote: > The most problematic parts are 3 and 4 since I cannot directly > test them neither on Darwin PPC nor on Linux PPC. I'll try to power up my Linux/PPC machine in the next couple of days so I can test this. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The most problematic parts are 3 and 4 since I cannot directly >> test them neither on Darwin PPC nor on Linux PPC. > > I'll try to power up my Linux/PPC machine in the next couple of days > so I can test this. Any news?

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

Hi Is there any Altivec optimized libVorbis implementation source code out there ? The only thing I'v found is that message: http://lists.xiph.org/pipermail/vorbis-dev/2003-October/007835.html but the link is dead, so the source code is lost (forever ?). I need to decode from 10 to 30 ogg files on my PS3 on the fly (files are already in memory, so I'm not I/O bound) and do something

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

good news, I finally got the asm compilation working with both autotools and project builder. it's all checked in. Brady, can you try it out too? autogen.sh may need a little tweaking depending on your environment. here's what mine looks like (I have some of the required libs in local places in the user acct that I build flac in, and the rest I get from Fink installed in /sw). aclocal