similar to: [LLVMdev] Patch to use correct namespace for 'find' in SetVector.h

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

On Tue, 12 Oct 2004 14:01:21 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > On Tue, 12 Oct 2004, Morten Ofstad wrote: > > > This is my first post on this mailing list, so bear with me... My name > > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > > makes 3D Visualization software. We are looking into using LLVM for JIT > >

Is it kosher to include vim mode line comments inside of LLVM source files? I would like to do this inside of the MicroBlaze backend to ensure that tabs are expanded into exactly two spaces. I see that right now the following files have these vim mode line comments: include/llvm/ADT/SetVector.h lib/Archive/ArchiveInternals.h lib/Linker/LinkModules.cpp lib/Transforms/IPO/DeadTypeElimination.cpp

From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm compiles fine; ours is compiled to a Debugging version. llvm-gcc, though, is angry. I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from

The code that I have written to get the function type is: const std::vector<Type *> ParamTys; ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(PointerType::get(Type::getVoidTy(Context), 0)); ParamTys.push_back(PointerType::get(Type::getVoidTy(Context), 0));

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

On 2009-05-15, at 07:26, David Greene wrote: > On Friday 15 May 2009 05:50, Jay Foad wrote: >> > >>> The one major thing to be aware of is that it isn't safe to use >>> &V[0] when V is an empty std::vector >> >> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >> is to switch to SmallVector whenever this might be a

Hello, This is my first post on this mailing list, so bear with me... My name is Morten Ofstad and I work for Hue AS (www.hue.no), a company that makes 3D Visualization software. We are looking into using LLVM for JIT compiling shader programs, to replace our own (slow) VM. A requirement for this is that we can compile LLVM in VS7.1, so I contacted Paolo Invernizzi to find the status of his

In the Ruby bindings, set_X and get_X are renamed to remove the get/set, so MSet::get_matches_estimated() becomes a read-only property (if I have my terminology right) of the Ruby MSet class called matches_estimated. This matches how a Ruby programmer would expect a class to be designed. I was looking through the getters and setters list. I wonder if a few entries shouldn't be there, (the

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

Hello - I am a fairly new user of R. I currently have R1.7 installed. I tried to install the KernSmooth package but a message tells me I need R1.8. Is there a way to update to R1.8 while in R1.7 in the same manner that I can use "update.packages", or do I have to install R1.8 in a separate directory and re-install the many packages I have already installed in R1.7? Thanks in advance for

Full_Name: Hsiu-Khuern Tang Version: 1.8.0 OS: GNU/Linux (Debian unstable) Submission from: (NULL) (156.153.255.243) Hi, I use palette(rgb(red=..., green=..., blue=..., names=mycolors)) to define my own color palette. After doing this, the names `mycolors' are not stored in palette() anymore, so that palette() returns a mix of built-in color names and RGB values. Eg: > palette()

Hello, since r243376 clang does not build with new libc++ anymore. Log attached. Reverting back lib/libc++ or not using libc++ fixes it. System: stable/9 amd64 r243742 WITHOUT_LIB32=yes WITHOUT_PROFILE=yes WITHOUT_SYSINSTALL=yes WITH_CLANG=yes WITH_CLANG_EXTRAS=yes WITH_CLANG_IS_CC=yes WITH_LIBCPLUSPLUS=yes CPUTYPE?=athlon64-sse3 CXXFLAGS+= -stdlib=libc++ -std=c++11 CC=clang CPP=clang-cpp

On 08/13/2009 07:35 PM, Matt Elder wrote: > From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm > using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm > compiles fine; ours is compiled to a Debugging version. llvm-gcc, > though, is angry. I get the following error (with path prefixes > shortened for convenience) when compiling llvm-gcc:

On Tue, 12 Oct 2004, Morten Ofstad wrote: > This is my first post on this mailing list, so bear with me... My name > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > makes 3D Visualization software. We are looking into using LLVM for JIT > compiling shader programs, to replace our own (slow) VM. A requirement Neat! > for this is that we can compile LLVM in

Full_Name: Alexander L. Belikoff Version: 2.8.1 OS: Ubuntu 9.04 (x86_64) Submission from: (NULL) (67.244.71.200) I'm trying to reshape the following data frame: ID DATE1 DATE2 VALUE_TYPE VALUE 'abcd1233' 2009-11-12 2009-12-23 'TYPE1' 123.45 ... VALUE_TYPE is a string and is a factor with only 2 values

Hi, Thanks a lot for the help! It seems that the SmallSetVector is the ADT I need (interface-wise). Is more efficient than llvm::UniqueVector? In my use case I have to insert a new element in the structure only if the element is unique. I hardly expect more than 32 elements. Do you think I gain a lot if I use the SmallSetVector instead of using SmallVector + slow searching on every

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

On Fri, Jan 08, 2010 at 05:04:17PM -0800, Chris Lattner wrote: > On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > >Hello, > > > >The CodeExtractor contains a std::set<BasicBlock*> to keep track > >of the > >blocks to extract. Iterators on this set are not deterministic, and so > >the functions that are generated are not (the order of the >