search for: czhang

Qualcomm is seeking for LLVM compiler developers for its OpenCL solution. This is full time position in San Diego, CA. You can check http://compilerjobs.com/db/jobs_view.php?editid1=316 for more detailed job description or directly send resume to czhang at qualcomm.com<mailto:czhang at qualcomm.com>. - Chihong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100413/cd92ecaf/attachment.html>

Hello, I have a self-defined function to be computed on each column in a matrix. The basic idea is to ignore the elements that have value of 0 during computation. I should be able to write my own function but it could be computational expensive, so I'd love to ask if anyone may have suggestions on how to implement it more efficiently. Thanks in advance. For example, there are three

Hello, I am using names function to name an array. It works first time when I use *as.numeric(names(myVar1)* However, at a place later, when I tried to use a very similar line of code *as.numeric(names(myVar2)*, it always returned 'numeric(0)' (or if I only type 'names(myVar2), it gave me NULL'. Both myVar1 and myVar2 are type of integer. The only difference that I can tell is

Hi, You might want to try running -loops -loop-simplify before loop unroll. >From loop simplify.cpp This pass performs several transformations to transform natural loops into a00011 // simpler form, which makes subsequent analyses and transformations simpler and00012 // more effective. Arushi On Tue, May 3, 2011 at 2:17 PM, Manish Gupta <mgupta.iitr at gmail.com> wrote: > You

Seems to me that they are using speex already. Ethereal shows that the voice RTP stream's payload type is 103. According to this page [ http://www.openh323.org/pipermail/openh323/2004-June/068705.html], 103 is SpeexNarrow-8k, although this email from Craig might not be correct. - Cheng > Message: 2 > Date: Thu, 25 Aug 2005 04:15:44 -0500 (CDT) > From: Ashhar Farhan

Hi Chris, It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make floating point type as scalable as int type. -Chihong -----Original