similar to: How to build LLVM such that `llvm::Module::dump() const' is preserved?

Kostya, all, I'm trying to build my project by clang 3.8rc1 with enabled asan (clang itself is address sanitized) and it fails on several files from my project (ISPC, https://github.com/ispc/ispc). I've reproduced this on MacOS and Linux. Please let me know if you need any other info. How to reproduce: 1) Build address sanitized clang 3.8rc1: cd /path-to-working-dir svn co

Hi, We are starting to work on an LLVM loop vectorizer. There's number of different projects that already vectorize LLVM IR. For example Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, AnySL, just to name a few. I think that it would be great if we could collaborate on the areas that are shared between the different projects. I think that refactoring LLVM in away that

> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think the idea is to keep NDEBUG out of headers when possible. So I think this should better be something like: > > -#ifndef NDEBUG > void dumpUses(unsigned RegNo) const; > -#endif > > to be inline with various other dumpers (like MachineInstr::dump(),

Nadav, You are absolutely right, it's ISPC workload. I've checked SSE4 and it's also severely affected. We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on

Nadav, Could you please have a look at bug #16941 and let us know what you think about it? It's performance regression after one of your commits. Thanks. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/036e81d6/attachment.html>

Nadav, The problem appears only for vectors longer than available hardware register (in doubleword elements, i.e. more than 4 on SSE4 and more than 8 on AVX). Select does weird thing. <8 x i1> mask comes as two XMM registers, select converts them to a single XMM registers (i.e. 8 x 16 bit), immediately after it converts back to two XMM registers and does blend. Conversion forth and back has

Hi All, I have tried to build llvm tip as following: cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm After running 'make', I have got error messages like below. llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function declared in class

Hi Nadav, ISPC is generating long vectors (on corresponding ISPC targets) this way since the every beginning of ISPC as far as I know. There's no such things in official LLVM documents as "illegal vectors", so people do expect that arbitrary long vectors are supported and generated reasonably well. Note, not super-optimal, but reasonably well. Keeping it this way allows considering

Hi Dmitry, Yes, this is a known problem with legalizing vector masks. The type <8 x i1> is legalized to 8 x i16, on SSE, but your operands are legalized to <4 x i32>. Type-legalization is performed per-node and we don’t have a good way to support instructions that mix the mask and operand type. Why does ISPC generate illegal vector types ? Does ISPC rely on the LLVM codegen to

Hi Dmitry, ISPC does some instruction selection as part of vectorization (on ASTs!) by placing intrinsics for specific operations. The SEXT to i32 pattern was implemented because LLVM did not support vector-selects when this code was written. Can you submit a small SSE4 test case that demonstrates the problem? Select is the canonical form of this operations, and SEXT is usually more

I think we should try to abstract the costs of instructions of various targets instead of trying to replicate them exactly. The coarser the costing infrastructure the more robust will be the vectorization pass. Also this eliminates/reduces the need of updating the costing infrastructure as and when new h/w reduces the cost(s) of existing instructions. - Dibyendu -----Original Message----- From:

Hi Dmitry. This looks like an ISPC workload. ISPC works around a limitation in selection dag which does not know how to legalize mask types when both 128 and 256 bit registers are available. ISPC works around this problem by expanding the mask to i32s and using intrinsics. Can you please verify that this regression only happens on AVX ? Can you change ISPC to use intrinsics ? Thanks Nadav Sent

Presently several of our headers have definitions like: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) void dump() const; #endif Would it make sense to modify the build system to define LLVM_ENABLE_DUMP in config.h on debug builds? Then we could wrap dump methods just based on LLVM_ENABLE_DUMP instead of two variables. -Chris > On Apr 10, 2017, at 1:34 PM, Robinson, Paul via llvm-dev

On Thu, Oct 13, 2011 at 02:37:54PM +0200, Duncan Sands wrote: > Hi Jack, > >> IMHO, the more important thing is to fish out the remaining regressions >> in the llvm vectorization code by defaulting -fplugin-arg-dragonegg-enable-gcc-optzns >> on in dragonegg svn once llvm 3.0 has branched. Hopefully this will get us wider >> testing of the llvm vectorization

Nadav, You are right, ISPC may issue intrinsics as a result of AST selection. Though I believe that we should stick to LLVM IR whenever is possible. Intrinsics may appear to be boundaries for optimizations (on both data and control flow) and are generally not optimizable. LLVM may improve over time from performance stand point and we would benefit from it (or it may play against us, like in this

----- Original Message ----- > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > To: "Nadav Rotem" <nrotem at apple.com>, "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 3:59:56 AM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > I think we should try to abstract the costs of

> On Apr 10, 2017, at 12:37 PM, Matthias Braun <mbraun at apple.com> wrote: > > The situation is not consistent. Yes there are several places where we have the #if in the headers however there are far more cases where it is not. Some points here: > > - This whole LLVM_DUMP_FUNCTION/LLVM_ENABLE_DUMP is about enabling the linker to strip (or not strip) the dumping function in

On 09/25/2017 02:53 PM, Matthias Braun via llvm-dev wrote: > The dump methods can be included in the release builds anyway by > enabling LLVM_ENABLE_DUMP. Is there a way to pass LLVM_ENABLE_DUMP into cmake from outside without changing any of the configuration files? With Chapel's use of LLVM, we try to avoid modifying any of the source files that come from the LLVM

Hi Matthias, >Jingu: Why do you even want a configuration that has LLVM_ENABLE_DUMP but does not have asserts enabled at the same time? My colleague and I am doing custom project using clang/llvm. We have always wanted to use the IR Value's dump() to check our implementation correctly with Debug, Release and another builds. We thought the LLVM_ENABLE_DUMP is for it. If Chris fixes

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 1:14:47 AM > Subject: [LLVMdev] LLVM Loop Vectorizer > > Hi, > > We are starting to work on an LLVM loop vectorizer. There's number of > different projects that