search for: vecorization

Dears, is there any way to "switch off" or work around the error message that pops up when I do something like: A<-B['logical vector'] and when 'logical vector' only consists of FALSE values? My problem is that this message always kicks me out of my loops and always testing via an if clause whether 'logical vector' contains any TRUE values is much too

I want to create a vecor with frequencies. I have tried this: a <- c(1,1,1,1,2,3,4,5,5) b <- table(a) print (b[1]) which results in: > print (b[1]) 1 4 The only thing I want is the 4. So this seems obvious: print (b[1,2]) but it does not work: Error in b[1, 2] : incorrect number of dimensions How do I get a vector or how do I refer to the "4" without getting the

Hi gruop, Pardon my question, but how could I import a excel file with 2 columns to R and then work with them as vecors. Thanks in advance,

Dear All, I am trying to build a program which will take repeated samples (w/o replacement) from a population of values. The interesting catch is that I would like the sample values to be removed from the population, after each sample is taken. For example: pop<-c(1,5,14,7,9,12,18,19,65,54) sample(pop, 2) = lets say, (5,54) ## This is where I would like values (5, 54) to be removed from

Dear All, I am trying to build a program which will take repeated samples without replacement from a population of values. The interesting catch is that I would like the sample values to be removed from the population, after each sample is taken. For example: pop<-c(1,5,14,7,9,12,18,19,65,54) sample(pop, 2) = lets say, (5,54) ## This is where I would like values (5, 54) to be removed from

Dear List, given a vecor of times in 5,15 and 30 minutes and a start point in time, lets say 09:30:00, how do I add up those times to the start time getting a cumulative time sequence? mt<-times(c('00:05:00', '00:15:00', '00:30:00')) mt wanted 00:05:00 09:35:00 00:15:00 09:50:00 00:30:00 10:20:00 Regards, Ren?

Hi all, on following code: ; ModuleID = 'shufxbug.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" define void @sample_test(<4 x float>* nocapture %source, <8 x float>* nocapture %dest) nounwind noinline { L.entry:

...is+transform AND analysis-only pre-passes, to allow a more fine grained control over vectorization (and ease tests of other passes that use Polly's info). > If the parallelism information is available outside polly, we can also > find some way to move code generation support for OpenMP, Vecorization > and CUDA from Polly to LLVM transformation library, after that we can > also generate such code base on the analysis result of the SCEV based > parallelism analysis. LLVM already has OpenMP support, maybe we should follow a similar standard, or common them up. CUDA would be closer to O...

...sis results into the polyhedral loop parallelism analysis pass. By doing this, other FunctionPasses/LoopPasses can query the parallelism information calculated by Polly. If the parallelism information is available outside polly, we can also find some way to move code generation support for OpenMP, Vecorization and CUDA from Polly to LLVM transformation library, after that we can also generate such code base on the analysis result of the SCEV based parallelism analysis. best regards ether > > 2. Full polyhedral code modification: use the annotation of the > previous pass to extensively modify...

<<<<<<<<<<<<<<<<<<<<<<<<<< ; ModuleID = 'shufxbug.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:6 4-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" define void @sample_test(<4 x float>* nocapture

> > Okay. If you'll update your local BBVectorize patches, then we can pull them upstream. Then we'll just need to update the unroller. If I understand this thread correctly, you want to enable vecorization by telling the BB vectorizer that different operations are independent. I understand your motivation and I agree that this is indeed one way to do vectorization. However, I don't completely understand something. If we already have the information that consecutive iterations of the loops are i...

On 02/18/2013 07:42 PM, Hal Finkel wrote: > Why don't we just add an optional iteration id to > !llvm.mem.parallel_loop_access? Sounds like a good idea to me. -- --Pekka

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Andrew Trick" <atrick at apple.com>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Monday, February 18, 2013

...s, to allow a more fine > grained control over vectorization (and ease tests of other passes > that use Polly's info). > > > > If the parallelism information is available outside polly, we can > > also find some way to move code generation support for OpenMP, > > Vecorization and CUDA from Polly to LLVM transformation library, > > after that we can also generate such code base on the analysis > > result of the SCEV based parallelism analysis. > > LLVM already has OpenMP support, maybe we should follow a similar > standard, or common them up. I wis...

Hal, I'm opening a new discussion on vectorization metadata, since it has little to do with fp-math. ;) What kind of metadata would you annotate in the instructions? If I remember from your talk, you're not doing any loop or whole-function analysis, possibly leaving it for Polly to help you along the way. I remember discussing it with Tobias that Polly could have three main steps: 1.

A friend has an old Pentium-133 laptop with 32MB of memory and a 1.3 GB hard disk that he wants to use as a web server for a very small community. Will CentOS (or any other RHEL derived distribution for that matter) install and run with acceptable performance on such a system, or will a specialized distribution like Damn Small Linux be a better choice? In this case, disk space is not a big

Hi folks, I've got this funny problem with R's foreign library when reading stata files. One file consistently produces vector out of memory errors after gobbling up 2.7G of memory. I parsed through the read.dta function and figured out where the error occurs and the description is below. I am running R-1.8.1 on Debian stable system glibc2.2 kernel 2.4.24. R is is compiled from source

Hi all, Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. ** Impact of Flipping the Switch ** * Upsides * For people developing on GlobalISel, it will: - Simplify the CMake command to type :) - Build/Test

> On Jan 14, 2017, at 4:57 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL

Looking through the archives I have seen talk of making CPU specific optimisations for Vorbis, a la MMX/3DNow!/SSE. The feeling I gather is to wait until something is working well in C before committing to any kind of specific optimisation. What if oft used and needed DSP functions were identified and standardised DSP functionality be written for Vorbis? This would seperate the basically