similar to: Damn!

Hi Nuno, Chandler, Nuno Lopes via llvm-dev wrote: > This program stores 8 bits, and leaves the remaining 24 bits > uninitialized. It then loads 16 bits, half initialized to %v, half > uninitialized. SROA transforms the above function to: > > define i16 @g(i8 %in) { > %v = add nsw i8 127, %in > %1 = zext i8 %v to i16 > %2 = shl i16 %1, 8 > %3 = and

On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It > didn't make a difference. So here are the failures for llvm-test. All > diffs are against the "native" output. > > ===================== MultiSource/Applications/sgefa > > cbe failed differently from jit/llc. First cbe: > > 84c84

On Sat, 11 Sep 2004 13:53:11 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > > > > ===================== MultiSource/Applications/sgefa > > > sgefa is a known XFAIL. See the nightly test results over the last > several months. Actually, you should compare your test results with the > 1.3 release test results

For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It didn't make a difference. So here are the failures for llvm-test. All diffs are against the "native" output. ===================== MultiSource/Applications/sgefa cbe failed differently from jit/llc. First cbe: 84c84 < One-Norm(A) ---------- 8.879153e+02. --- > One-Norm(A) ---------- 8.879156e+02.

> On 11/8/2016 3:32 PM, Sanjoy Das wrote: >> Hi Nuno, Chandler, >> >> Nuno Lopes via llvm-dev wrote: >> > This program stores 8 bits, and leaves the remaining 24 bits >> > uninitialized. It then loads 16 bits, half initialized to %v, half >> > uninitialized. SROA transforms the above function to: >> > >> > define i16 @g(i8 %in) {

Dear R Help, I read through the archives pretty extensively before sending this email, as it seemed there were several threads on using predict with GLM. However, while my issue is similar to previous posts (cannot get it to predict using new data), none of the suggested fixes are working. The important bits of my code: set.seed(644) n0=200 #number of observations

Caleb wrote: > i dont understand you people. >-q0 should be poor quality, only that in vorbis, the poor quality is > actually good! :) Another advantage I see in reducing the nominal bitrate for q0 to 48kb/s with a ~13khz lowpass is a smoother transition in average bitrate and frequency resolution from 22khz to 44khz sampling. Currently there is a jump from 11khz (at 22khz

Hi all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

Hello, I am trying to reach a web service using the SOAP package. I succeeded calling the web service, but not sending parameters to it. After much research and tries, I think I found that the problem lies in the namespace including the parameters in the SOAP body. In short, my question is: how can I send unqualified parameters in the SOAP body of a call produced through the SOAP package?

Hi, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

Hi Everyone, I posted this a couple of weeks ago with no responses. My interface (via gmane) seemed a bit flakey at the time, so I'm venturing to repost with some additional information. I'm trying to write selfStart non-linear models for use with nls. In these models some combinations of parameter values are illegal; the function value is undefined. That's OK when calling the

As the subject implies, my question is: is it possible to use the -b (or -M) flag at non-44K sample rates? I'm working with an application that is trying to optimize for very small audio filesize. I found that downsampling to 11K and then using q0 gives high compression, but won't seem to drop below 64kbps or so. It seems like the combination of downsampling, then reducing to 30kps

I've filed a bug for aarch64 https://github.com/xiph/speexdsp/issues/7 and provided the port in a fork with a pull request. We need someone to review/merge in the pull request? It provides the source code, but my testing was under Android builds, so there would be some configure changes needed to build it stand alone. On Tue, Apr 19, 2016 at 4:32 PM, Frank Barchard <fbarchard at

I am writing a long-run sound recording application using OggVorbis. The user can adjust sound quality parameter to make balance between storage space and sound quality. The input sound is 22050Hz, mono. To maximize the recording capability on a given storage volume, we want the result bitrate as low as possible. I use -q0 parameter and it produces a 32.0kbps stream. It is too high (our

ARGH! I am at a complete loss as to which OGG quality settings to use: 8? 10? 3? I'd like to be able to listen to my primarily Rock oriented music on a high-end system (though I don't own one - yet) without any noticeable sound degradation, but I don't want to go total overkill with -q 10. With LAME, I at least used to know 192 kbps with -q0 was a perfect size/quality proportion. I

LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I made these nifty pythonscripts to make my ripping+encoding+sorting easier. They are designed to use in Grip. w_oggenc: Call this instead of oggenc in Grip with the command-line: "%A" "%d" "%t" "%a" "%n" "%y" "%G" "%i" Now you can put additional info in the

On Tue, Apr 25, 2017 at 10:31 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > > > A_Q28 is split to 2 14-bit (or 16-bit, whatever) integers, to make the > > multiplication operation within 32-bits. NEON can do 32-bit x 32-bit = > > 64-bit using 'int64x2_t vmull_s32(int32x2_t a, int32x2_t b)', and it > > could possibly be faster and less

HI James, Thanks for your reply and hints on what can be done for the Aarch64 backend optimization for llvm We have SPEC license and v8 hardware. So I will start looking into it warm regards Manjunath On Wed, Jun 25, 2014 at 8:42 PM, James Molloy <james.molloy at arm.com> wrote: > Hi Manjunath, > > At the time of writing that status we had only done our initial analysis. >

I was up late last night, and i had a thought on peeling that would probably provide 100% accurate peeling data to a decoder, but take a maximum of 1101 times normal time to encode (taking into account the range from q-1 to q10 ). ay you want to encode a track at q10, but you want it to be peelable. the 1101 encoder would encode from the source at every quantifiable level (since there are 2