similar to: [LLVMdev] Experimental C64X backend

On Thu, 2010-08-12 at 12:03 +0200, Jeremy Morse wrote: > Hi, > > Over the past few months I've been developing a LLVM backend for TIs > C64X family of DSPs. It can be found as a co-processor in a variety of > OMAP-based devices Interesting! > The code itself can be found in the git repo at [2] and is based on LLVM > 2.7. (Binutils is at [3]). Are you intending to

Hi, I'm glad to see some action with regard to static instruction scheduling and VLIW support in LLVM. I have some questions and remarks which might not be relevant as I'm not totally familiar with the current code generation framework of LLVM nor your plan. On 12/02/2011 10:40 PM, Evan Cheng wrote: > 2. It must be flexible enough to represent more than VLIW bundles. It should be >

Hi, Basically, inner_prod() can and should be adapted to the architecture it will run on. It is not really sensitive to noise, so it's possible to tweak it a lot. Also, in the current code, I saturate it to +-16384, which is OK to prevent overflows. I'm not concerned with the case of a constant -16384 value because it can't really happen in practice (especially after filtering). BTW,

Hello ! I am developing a kind of phone using TI's OMAP 5912 and speex. The soft works great on ARM, and it is time to move speex and voice processing stuff to DSP. Could some one point me how to do it ? Should I install CCS ? Or it possible to compile speex using just ti_dsptools ? Does anybody ran speex and dsp gateway ? It would be great, if some one share makefile, cmd etc. for

Hi, On ARMv6T2 this turns cttz into rbit, clz instead of the 4 instruction sequence it is now. I'm not sure if adding RBIT to ARMISD and doing this optimization in the legalize pass is the best option, but the only better way I could think of doing it was to add a bitreverse intrinsic to llvm ir, which itself might not be the best option since bitreverse probably isn't too common. Other

Using -export-symbols-regex all private symbols are hidden, resulting in the following changes: libkms: removes all driver specific exports radeon: removes the bof_* exports nouveau: removes the abi16_* exports freedreno: remove the *kgsl_* and msm_* exports intel: removes the drm_mm* exports omap/exynos: unchanged as far as I can tell Signed-off-by: Maarten Lankhorst <maarten.lankhorst at

Hi, i'm not an expert in dsp but i've seen there is some code to run speex on omap C5X dsp so i was wondering what is the status of this code. Actually my goal is to run a voip application which uses gstreamer on an OMAP 5912 board. As there is already a speex codec for gstreamer, i was wondering if this plugin can already use the dsp power or if there is the need for a new plugin. thank

Since OMAP UART has a few distinct features than common 8250 UART, I re-implemented its driver rather than porting it based on ns16550.c. There are mainly two big differences between the implementations. First, OMAP UART introduces the concept of register access mode, which divides the register map into seperated space. Switching the access mode is then necessary when configuring it. Second, THRE

Hi, I'm porting speex as a DSP task to run using the DSP gateway project. I have some results, but I still need some improments, because I'm still getting some error messages in the mail box system... If someone wants to help... it would be useful. 2006/1/16, Ralph Giles <giles@xiph.org>: > On Mon, Jan 16, 2006 at 04:43:56PM +0100, Christophe Augier wrote: > > >

In my daily development, I migrate back and forth between versions, and often do: rake load_fixtures... ... in order to populate my development database with fun data. Now, with any HABTM relationship, there are failures, as there is no way to say "which" fixtures to load first. Within an actual functional or unit test case, you could simply load them in the proper order, but

On 15 Jan 2010, at 18:03, Chris Lattner wrote: > On Jan 14, 2010, at 10:13 PM, David Conrad wrote: > >> Other targets that I know of that could potentially benefit from >> this optimization being global (that have a clz and bitreverse >> instruction but not ctz) are AVR32 and C64x, neither of which llvm >> has backends for yet. > > When/if another

Hello The current crypto_engine support only ahash and ablkcipher. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct engine and

Hello The current crypto_engine support only ahash and ablkcipher. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct engine and

2006/1/17, Christophe Augier <christophe.augier@gmail.com>: > > I'm porting speex as a DSP task to run using the DSP gateway project. > > I have some results, but I still need some improments, because I'm still getting > > some error messages in the mail box system... If someone wants to > > help... it would > > be useful. > > that's some

On Jan 14, 2010, at 10:13 PM, David Conrad wrote: > Hi, > > On ARMv6T2 this turns cttz into rbit, clz instead of the 4 > instruction sequence it is now. > > I'm not sure if adding RBIT to ARMISD and doing this optimization in > the legalize pass is the best option, but the only better way I > could think of doing it was to add a bitreverse intrinsic to llvm

Thomas, I am experimenting with virtual links and cannot seem to get this to work right. I copied the htmldoc.virtual file out of the mics folder that was bundled with webgen5.4 and pasted that into my src directory. I then edited the file to the link I wanted to use. api.html url: http://mylink.com title: This is my link in_menu: true sort_info: 60 The link is in the menu for the

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already

<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.

Bug #4521 has been filed. traps.c has been also attached. Thanks, Won On Wed, Jul 8, 2009 at 1:38 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o >

> I suggest that you start by looking at 8kbps, complexity 0. Actually, I strongly recommand *against* using complexity 0, unless you're really desperate for a few MIPS. The complexity reduction compared to 1 is small, but the loss in quality can be significant. > I (and others) > are running that on a TI C55xx DSP, and it runs a little under 30 MIPs when > I last checked, with