similar to: [LLVMdev] why 'const' void * return for ThreadLocalImpl::getInstance()?

Reza Sheykhi <hajishey at msu.edu> writes: > I got the following answers: > > which perl > /usr/bin/perl > > which llvm-config > /usr/local/bin/llvm-config > > which llvm-as > /usr/local/bin/llvm-as > > /usr/bin/llvm-confing --version > bash: /usr/bin/llvm-confing: No such file or directory Uh, there is a typo on the command above, it should be

I got the following answers: which perl /usr/bin/perl which llvm-config /usr/local/bin/llvm-config which llvm-as /usr/local/bin/llvm-as /usr/bin/llvm-confing --version bash: /usr/bin/llvm-confing: No such file or directory /usr/local/bin/llvm-config --version 2.8 Quoting Óscar Fuentes <ofv at wanadoo.es>: > Reza Sheykhi <hajishey at msu.edu> writes: > >> Thank you

Hi, LLVM/Clang version: 3.2svn (r156975). I have a bitcode file that I'm trying to load/execute using lli as below but it reports an error about unresolved symbol: > LLVM ERROR: Program used external function '_ZNKSt3__16locale9use_facetERNS0_2idE' which could not be resolved! > lli: /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/llvm/lib/Support/ThreadLocal.cpp:54:

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at

I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure. Once you allow inlining, you're pretty much telling your users they had better give you compatible definitions. We wanted to make sure that if users gave us compatible defs (mainly: same source, but optimized in one CU and not in another),

Resending, any pointers? I demangled the symbol and it turns out to be: std::__1::locale::use_facet(std::__1::locale::id&) const tia, ashok On 5/19/2012 9:41 PM, Ashok Nalkund wrote: > Hi, > LLVM/Clang version: 3.2svn (r156975). I have a bitcode file that I'm > trying to load/execute using lli as below but it reports an error about > unresolved symbol: >> LLVM

Hi, > I am very sorry to trouble you, but I need your help about my problem about > ThreadLocalImpl in llvm of 2.8 version. this is a very old version of LLVM, I suggest you try something newer, eg the recently released version 3.1. Best wishes, Duncan. I have compiled it in Windows xp with > mingw, and have compiled skyeye(an open source project about simulator) as it > uses

I'm trying to use the Support/ThreadLocal class, and I'm having some trouble because ThreadLocalImpl::getInstance returns a const void*, which I would like to be able to modify. Is there any particular reason this returns a const pointer rather than simply a void pointer? Pthreads and the Windows TLS API both seem to return plain void*. If there's no particular reason for this,

Hi, everyone: I am very sorry to trouble you, but I need your help about my problem about ThreadLocalImpl in llvm of 2.8 version. I have compiled it in Windows xp with mingw, and have compiled skyeye(an open source project about simulator) as it uses llvm. But when I run a testcase ---- arm_hello, it came out segment fault. I used gdb.exe to trace it, it gave the following infomation: $

Agreed, done. One thing I'm not sure about is this statement in docs: POSIX.1-2008 marks *rand_r*() as obsolete. - And... what is the replacement? 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > If we're keeping the state locally now, perhaps we should store it in a > per-thread variable. I know rand() isn't thread safe to begin with, but it > seems

> On Feb 25, 2016, at 12:02 PM, Andy Ayers via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure. Yes, my understanding is that this is what Chandler suggested when he wrote as part of his plan: 2) Teach frontends to emit (even at

On Thu, Dec 17, 2015 at 9:21 AM, Andy Ayers <andya at microsoft.com> wrote: > While your bb count distribution is extremely likely to be some kind of power-law like distribution, it's not guaranteed. > > Also you might think about operations that can amplify (rerolling) or appear to amplify (TRE) or diminish BB counts, and how you'd go about reclassifying block hotness. yes

On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at microsoft.com> wrote: > For non-LTO compiles: block bottom-up propagation of facts that > depend on optimization levels -- eg register kills and parameter usage > summaries. Allow other IP information to flow upwards, since at least > in our world all comdat-foldable definitions are supposed to be > "equivalent".

On Wed, Dec 16, 2015 at 6:00 PM, Andy Ayers <andya at microsoft.com> wrote: > I’ve done similar rankings with profile data and found it worked out pretty > well. > > > > In my case it was ranking function hotness but the idea was similar: sort by > weight, compute various percentile cutoff points, and use those to classify. > I put in some compensation for truly

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific

A couple things I recall from implementing this in Phoenix: For LTO -- do your comdat folding as part of the up-front symbol resolution before invoking the backend (saves compile time too). Then have the linker ensure that the comdat from the LTO bundle is the winner in the final link step. That way during LTO you know which method body is going to be in the final image. May not be as easy in

These patches should be ready to go in now; I will also post my work-in-progress for enabling full parallel handling that depends on these, but with that series, I was still getting crashes or hangs with test-socket-activation (I think I've nailed all the crashes I've seen, but the hang is rather insidious; see my other email

On 11/16/2017 09:13 PM, Eric Blake wrote: > We can't guarantee what storage duration the caller's request > for a thread name has; and in fact, if the caller uses > plugin_name() for their thread name, then the moment .unload > is called, our threadlocal storage is pointing to la-la-land > and we get a nice SEGV while trying to print any debug message. > So copy the

Version 1 was here: https://www.redhat.com/archives/libguestfs/2019-April/msg00144.html Version 2 makes a couple of much larger changes: The OCaml patch changes the API of the pread method so it matches what other language bindings are already doing, ie. get the language plugin to return a newly allocated buffer, check it is long enough, copy out the data. The server patch implements a

In other compilers I've worked on there were special pseudo instructions (or similar mechanisms like adding extra source operands to returns) that allowed you to artificially extend lifetimes of values. For instance we might have a requirement that a certain local (say the 'this pointer') remain live throughout the method. Is there anything like this in LLVM? -------------- next part