similar to: [LLVMdev] Turning on/off sub-target features (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

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

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

On 9/17/2019 3:17 AM, Renato Golin wrote: > Hi Philip, > > Apologies for leaving this thread linger so long. It was in my > back-burner but Alex's weekly remind me to reply (thanks again, > Alex!). Starting from the end... > > On Mon, 9 Sep 2019 at 18:53, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Current Plans >> >> At

Looks like LLVM support in Mono has matured to the point they're willing to advertise it: http://tirania.org/blog/archive/2009/Jul-16.html Paul PS Zoltan, sorry if I stole your opportunity to break the news :)

Sorry for being a newbie on the matter, but could someone explain the comment (in response to: "Considering it [LLVM] supports three other languages with try/catch clauses just fine (C++, Ada, and now, Java), I think it would be incorrect to say "it is not able to support some of the features"."): ------------------------------ The issue is that the exception handling as

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