similar to: [LLVMdev] LLVM program compile error w/ gcc 4.5 but not 4.4

Nick Lewycky wrote: > > > > It's maintained by LLVM for you, by Value::setName and other methods. > > Nick > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > I am getting the following error when trying to

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

Hi, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we

I haven't tested it, but it looks to me like llvm-profdata merge (well, InstrProfWriter specifically) would not have deterministic output. Certainly the textual output iterates over FunctionData which is a StringMap of SmallDenseMaps, neither of which has deterministic iteration. The binary writing looks like it'd have similar issues - looping through these unordered maps & writing

On Thu, Jun 29, 2017 at 7:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> > wrote: > >> On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I haven't tested it, but it looks to me like llvm-profdata merge (well,

On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> wrote: > On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> I haven't tested it, but it looks to me like llvm-profdata merge (well, >> InstrProfWriter specifically) would not have deterministic output. >> >> Certainly the textual output iterates

Hi all, I'm dealing with the multi-threaded code, in one of executions of the program I hitting an assertion failure, I'm not always getting the assertion failure when I run the executable but it occurs for say (1 in 10) times. I think there may be an thread race condition. I don't know which is the root cause of this error because the assertion not explicitly occurs in my code, it

HI, Developers: I linked libLTO.so in $LLVMROOT/Debug/lib however, my program crashes in assertion at 149line [Pass.cpp] void RegisterPass(const PassInfo &PI) { bool Inserted = PassInfoMap.insert(std::make_pair(PI.getTypeInfo(),&PI)).second; assert(Inserted && "Pass registered multiple times!"); } i confirm that there is only one static variable

On Sun, Mar 1, 2009 at 4:24 AM, Nick Lewycky <nicholas at mxc.ca> wrote: Please try this patch. I tried to copy exactly what libtool would do on Cygwin by reading the libtool source. Hi Nick, Working fine on Cygwin :) Aaron Nick Aaron Gray wrote: On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com <mailto:aaronngray.lists at

Aaron Gray wrote: > On Sun, Mar 1, 2009 at 4:24 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Please try this patch. I tried to copy exactly what libtool would do > on Cygwin by reading the libtool source. > > > Hi Nick, > > Working fine on Cygwin :) Great to hear! I've committed the fix in r65922.

Hi, for some temporary debugging I wanted to know what sort of Value I was seeing, and I ran across this comment in Value.h - it's probably a minor point, but unless I'm missing something I think either the last line of the comment is wrong or the code is. It appears in rev 1.58, as part of fixing bug 122. 00134 /// getValueType - Return an ID for the concrete type of this object.

> Date: Wed, 26 Oct 2011 11:52:50 -0700 > From: Tanya Lattner <lattner at apple.com> > Subject: [LLVMdev] Release Notes: Volunteers needed > We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go > through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. > Ideally,

On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> >> Could you please rig Makefile.rules or something to print out the value >> >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if >> >> that's

Hi Devs, Consider below testcase. $cat test.cpp #include <vector> #include<type_traits> typedef int _int4 __attribute__((vector_size(16))); typedef union{ int data[4]; struct {int x, y, z, w;}; _int4 vec; } int4; typedef int4 int3; int main() { static_assert(std::alignment_of<int4>::value <= alignof(max_align_t), "over aligned!"); } $clang++ -m32 error:

Look I have written a PRE pass. opt is running that pass. I have included my pass name there in include/llvm/Support/StandardPasses.h file. To do that, I have got some error. Because it also requires the definition of the pass in some other file also. I observed how gvn pre pass is added to the pass list. I had followed the same way, but failed. Cna you kindly tell what needs to be done in this

Hi, For the following case, $ cat bad1.ll target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64" define internal void @test(i32 %v) { entry: %tmp = alloca i32, align 4 store i32 %v, i32* %tmp, align 4 %0 = bitcast i32* %tmp to <2 x i8>* %1 = load <2 x i8>* %0, align 4 ret void } I

On Nov 29, 2010, at 11:07 AM, Zhanyong Wan (λx.x x) wrote: > C++ is such a complex language that no single naming convention will > be able to cover all cases. Therefore we aim at a reasonable default > that works for the majority of the cases. As Chris put at the > beginning of the coding standards, "no coding standards should be > regarded as absolute requirements to be

Soumya_Prasad_Ukil wrote: > Look I have written a PRE pass. opt is running that pass. I have > included my pass name there in include/llvm/Support/StandardPasses.h > file. To do that, I have got some error. Because it also requires the > definition of the pass in some other file also. I observed how gvn pre > pass is added to the pass list. I had followed the same way, but failed.

On Feb 24, 2011, at 8:14 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> class CodeGenOpt { >>> ... >>> public >>> getOptLevel() ...; >>> getFPLevel() ...; >>> getMemLevel() ...; >>> }; >>> >>> Does this sound reasonable? >> >> I don't think that this is

Hi, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a