similar to: [LLVMdev] llvm-stress for fuzzing llvm

Nadav, Thanks, this is neat! Here is a patch which optionally enables generation of the other floating-point types. Please review. -Hal On Sun, 26 Feb 2012 11:51:04 +0000 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi, > > Compiling lots of 'junk' helps in catching bugs. I added a new tool > (located under llvm/tools/llvm-stress) for generating

Wow, nifty tool! I've already found a couple crashes! It is also really easy to pinpoint what is causing the error. Whenever you trigger a bug, run llvm-stress with the same seed but a really small size that doesn't trigger the bug (e.g. like 10). Then do binary search on the size. Eventually you find exactly the cutoff of size that triggers the bug (e.g. 539 runs fine, but 540 crashes),

Sean, Thanks for looking at this. Knowing that the last instruction triggered the bug is often not enough. I use bugpoint to reduce the failing test. The reason is that some of the bugs may be caused by the interaction between several instruction. Having said that, I think that the change that you proposed is a good one. Can you send a patch ? Thanks, Nadav From: Sean Silva

I'm finding it useful to replace the main loop with: for (unsigned i = 0, n = SizeCL/Modifiers.size(); i < n; ++i) { Modifiers[i%Modifiers.size()]->Act(); } That way, changing the size by 1 adds exactly one instruction, which makes delta debugging MUCH easier. Maybe it would be worth changing? --Sean Silva On Sun, Feb 26, 2012 at 9:23 PM, Sean Silva <silvas at

Here is that patch. Btw, I've just been using bugpoint, and it's really nifty! --Sean Silva 2012/2/27 Rotem, Nadav <nadav.rotem at intel.com> > Sean, > > Thanks for looking at this. Knowing that the last instruction triggered > the bug is often not enough. I use bugpoint to reduce the failing test. > The reason is that some of the bugs may be caused by the

Hi, Last week I wrote llvm-dev and presented data that shows how enabling the vectorizer on -Os can improve the performance of many workloads and that it has negligible effects on code size. I also added a command line switch to make it easier for people to benchmark the vectorizer using -Os directly from clang without changing LLVM. Has anyone done any benchmarks on -Os + vectorization ?

Nadav, Please forgive my ignorance, but 'opt -mcpu=corei7 -loop-vectorize -S -debug double.ll' doesn't appear to make a difference. In fact it seems to be ignored as garbage values for -mcpu don't raise an error. Am I overlooking something else also? Many Thanks, Josh On Thu, May 9, 2013 at 6:06 PM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Josh, > > Your

On 5/7/2012 12:21 AM, Bendersky, Eli wrote: <snip> > > MCJIT is functional in trunk (and the 3.1 branch). While it doesn't include all the features of the old JIT quite yet, it's complete enough to pass all of JIT's execution tests on Linux and Mac OS X (no Windows yet). As for directions on how to enable it, follow the path of the "use-mcjit" flag passed to lli

Hi Josh, This line works for me: opt file.ll -loop-vectorize -S -o - -mtriple=x86_64 -mcpu=corei7-avx -debug You need to specify the triple on the command line if it is not inside the module. Thanks, Nadav On May 9, 2013, at 5:53 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > Please forgive my ignorance, but 'opt -mcpu=corei7 -loop-vectorize -S

Sorry for the delays here. I am running our benchmark suite and will have data in a day or so. On Jun 13, 2013 9:40 PM, "Nadav Rotem" <nrotem at apple.com> wrote: > Hi, > > Last week I wrote llvm-dev and presented data that shows how enabling the > vectorizer on -Os can improve the performance of many workloads and that it > has negligible effects on code size. I

Hi Rotem, Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? Best Regards Seb > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Thursday, July 05, 2012 11:21 AM > To: Sebastien DELDON-GNB; llvmdev at cs.uiuc.edu > Subject: RE: Vector argument passing abi for ARM ? > > The

Hello everyone, I wanted to let everybody know that I am going to enable the support for vector-select by default later today. Details: Currently the LLVM code-generator only supports 'select' [1] instructions with a boolean condition. Vectorizing compilers, such as the Intel OpenCL Vectorizer and the GCC vectorizer often use vector-select instructions to implements masks. This change

| |Hi Elena, | |Technically speaking, this seems straightforward. | |I wonder, however, how target-independent this is in a practical |sense; will there be an efficient lowering when targeting any other |ISA? I don't want to get into the territory where, because the |vectorizer is supposed to be architecture independent, we need to |add target-independent intrinsics for all

| |How would this work in this case? The result would need to affect the |legality and cost of the memory instruction. From your poster, it looks |like we're talking about loops with constructs like this: | |for (i =0; i < N; i++) { | if (topVal > b[i]) { | *dst = a[i]; | dst++; | } |} | |is this loop vectorizable at all without these constructs? Good

Hi Andrew, I think I diluted my question. My question was not related to MCJIT. I ran the following 4 scenarios: (1)gcc -mcpu=corei7 tetris.c -o tetris (2)gcc -mcpu=athlon64 tetris.c -o tetris (3)clang -march=corei7 tetris.c -o tetris (4)clang -march=athlon64 tetris.c -o tetris In (1) and (2), I see difference in order of instructions in the output binaries, which I expected because every CPU

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > I can think of two ways to represent masks in x86: sparse and > packed. In the sparse method, the masks are kept in <4 x 32bit> > registers, which are mapped to xmm registers. This is the ‘native’ way > of using masks. This argues for the sparse representation, I think. > _Sparse_ After my discussion with

Hi Varun, I see the point of your question, but I'm not the best person to answer from that perspective. Nadav Rotem is the owner of the x86 backend, and he can probably give you a more complete answer than I could. Thanks, Andy From: Varun Agrawal [mailto:vagrawal at cs.stonybrook.edu] Sent: Friday, October 11, 2013 8:48 PM To: Kaylor, Andrew; llvmdev at cs.uiuc.edu Subject: RE: Building

Hi all, AVX-512 ISA introduces new vector instructions VCOMPRESS and VEXPAND in order to allow vectorization of the following loops with two specific types of cross-iteration dependencies: Compress: for (int i=0; i<N; ++i) If (t[i]) *A++ = expr; Expand: for (i=0; i<N; ++i) If (t[i]) X[i] = *A++; else

Hi, I'm using LLVM/clang from release 3.0. I have a program (C++) that will load a library in the form of LLVM bit code using the JIT. However, I see JIT errors when loading the bit code: "LLVM ERROR: JIT does not support inline asm" I read that MC JIT intends to fix this. I'm trying to build LLVM from the lastest trunk. Is there any special/extra thing to do to use

Hello, I started working on adding vector support for the SELECT and CMP instructions in the codegen (bugs: 3384, 1784, 2314).  Currently, the codegen scalarizes vector CMPs into multiple scalar CMPs.  It is easy to add similar scalarization support to the SELECT instruction.  However, using multiple scalar operations is slower than using vector operations. In LLVM, vector-compare operations