search for: c64x

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 keep the development separate or merge to both projects'...

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 such as gumstix, beagleboard and even Nokia's N900 phone. A project I'm working on [0] has had need to put code on it, and we wanted to avoid TIs proprietary compiler. The DSP itself is a VLIW machine, wit...

...to add a bitreverse intrinsic to llvm ir, which itself might not be the best option since bitreverse probably isn't too common. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-ctz-arm.diff Type: application/octet-stream Size: 5160 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100115/9da482e2/att...

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,

...an 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 target wants this, we could add a ISD::RBIT operation, > it doesn't need to be added at the llvm ir level, The XCore also has ctlz and bitreverse instructions and not cttz. At the moment in the XCore backen...

...bably isn't too common. I haven't looked at the patch in detail, but this approach makes sense to me. > 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 target wants this, we could add a ISD::RBIT operation, it doesn't need to be added at the llvm ir level, -Chris

...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 target wants this, we could add a ISD::RBIT >> operation, >> it doesn't need to be added at the llvm ir level, > > The XCore also has ctlz and bitreverse instructions and not cttz. At...

...gt; >>> 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 target wants this, we could add a ISD::RBIT >>> operation, >>> it doesn't need to be added at the llvm ir level, >> >> The XCore also has ctlz and bitreverse...

...to formulate a constraint like this: let Constraints = "${src:sub_even} != $dst" in { ... } , that is, only if a subregister of $src != $dst then ...? Perhaps this is entirely the wrong way anyway. I'm trying to implement (s/z/any)ext & trunc from 32 to 64 bit integer on a TI C64x processor. 64 bit ints are always stored in two adjacent registers (not uncommon, cf. SystemZ and Sparc float). The processor does not have a special instruction for this (unlike Sparc, if I'm not mistaken), so it basically boils down to a "mv ${src:sub_even}$dst". Obviously, this...

...anger with the summation of four > mults overflowing the 32 bit before the shift. > > I can fix this by accumulating each term into a long, but if the code scales > the x[],y[] vectors to avoid this problem I could use parallel 16x16 > multiply/adds. What do you mean here? The C64x has a _dotp2() instruction that does two 16x16 multiplies and adds the products together. Since the values are scaled to 16384, I can add the results of the two _dotp2()s together before the long add without worrying about overflow. I didn't understand that inner_prod() was always passed scal...

I am trying to implement a relatively high number of encoders (24/32) on a single DSP and would like to minimize the memory requirements. Has anyone optimized the persistent EncState memory allocation for multiple channels. The default C64x fixed point implementation allocates 5280 bytes of persistent memory per encoder. I'm willing to restrict my settings to complexity 1, quality 3. It looks like I can share the st->window, lagWindow, bw_lpc1, bw_lpc2, variables which would save 562 bytes per encoder. Are there more variab...

<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. It takes two integer operands of the same width, and returns an integer with twice the w...

...on. > > I haven't looked at the patch in detail, but this approach makes sense > to me. > >> 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 target wants this, we could add a ISD::RBIT operation, > it doesn't need to be added at the llvm ir level, Bit reversal turns up in most FFT algorithms, so it wouldn't hurt to be able to add an instcombine t...

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

...ith modifications to arch.h, bits.c, and misc.c. This contains the few mods remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max buffer size, change MAX_BYTES_PER_FRAME to MAX_CHARS_PER_FRAME for consistency misc.c: Added override switches to alloc routines, conditional include of user file changes to allow manual memory allocation rather than using heap...

...f still works with > that? In the end, it'll probably make things easier for you now. For > example, if you link statically, wideband should be automatically left > out if unused. Also, all the libc stuff is now in os_support.h, which is > less messy than misc.h/misc.c were. The TI C64x build produces bit-exact results with build 12825 (April 2007, a bit before 1.2beta2). The C54x and C55x builds did not work because the manual allocation scheme was broken when misc.c was removed. The old override mechanism was: 1. Define USER_MISC in config.h 2. In, misc.c, include user_mi...

> 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

...t; that? In the end, it'll probably make things easier for you now. For >> example, if you link statically, wideband should be automatically left >> out if unused. Also, all the libc stuff is now in os_support.h, which is >> less messy than misc.h/misc.c were. > > The TI C64x build produces bit-exact results with build 12825 (April 2007, > a bit before 1.2beta2). The C54x and C55x builds did not work because the > manual allocation scheme was broken when misc.c was removed. > > The old override mechanism was: > > 1. Define USER_MISC in config.h &gt...

...n Lebedev" <lebedev.ri at gmail.com>: > On Sun, Jul 5, 2020 at 12:18 PM Shawn Landden via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more. >> >>  This proposal is to add a llvm.clmul instruction. Or if that is contentious, llvm.experimental.bitmanip.clmul instruction. It takes two integer operands of the same width, and returns an integer with twice the width of the operands. (Is there a good reason to...

...t the difference > wouldn't be very large. Note that the quality isn't be as good with that > option on, whereas the changes I made recently don't hurt quality. > > Jean-Marc > -------------- next part -------------- A non-text attachment was scrubbed... Name: testenc-TI-C64x.c.patch Type: application/octet-stream Size: 5143 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060424/82413d6a/testenc-TI-C64x.c-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: arch.h.patch Type: application/oct...