similar to: [LLVMdev] UPCOMING API CHANGE: Threads and LLVM

This question is a bit of far away future thought: There's traditionally been a fundamental assumption that static compilers are single-threaded. Many build systems assume this and support assigning compilation jobs with one job per processor. If the compiler becomes multi-threaded internally, how should the build system best schedule compilation jobs? deep On Mon, Jun 15, 2009 at 6:16 PM,

+chandlerc, aaronballman, in case there are additional carryovers and/or issues from the review thread which I've left out. I have a patch up for review[1, 2] that attempts to replace LLVM's mutex implementation with std::mutex and std::recursive_mutex. While the patch seems to work, there are questions surrounding whether or not the approach used is correct. I'll try to summarize

Hi, Why are there so many undocumented (and as I far I can see) unnecessary API changes? Recently there has been: 1. For JIT applications, please include llvm/Target/TargetSelect.h and call the llvm::InitializeNativeTarget() function before creating an EE. 2. The major CHANGE is: the JIT will no longer be safe for executing threaded applications without first invoking

Thanks. I think I am using Apple GCC 4.2. i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) Should I use something else for LLVM? - xi On Sun, May 24, 2009 at 1:20 AM, Owen Anderson <resistor at mac.com> wrote: > > On May 23, 2009, at 9:41 PM, Xi Wang wrote: > > There is no __sync_synchronize or __sync_val_compare_and_swap on Mac > OS X.  One might use

On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod

No, that should work fine, and is exactly what I use to compile atomics on Darwin. --Owen On May 23, 2009, at 11:02 PM, Xi Wang wrote: > Thanks. I think I am using Apple GCC 4.2. > > i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) > > Should I use something else for LLVM? > > - xi > > On Sun, May 24, 2009 at 1:20 AM, Owen Anderson <resistor at

On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion <peter.zion at fabric-engine.com> wrote: > Hello, > > I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. > > - I am using the official

In our experience, as Owen also suggests, a pragma or a language extension can be avoided by a combination of static and dynamic analysis. We prefer this approach in our compiler ;) Regards, Vinod On Sat, Jan 24, 2015 at 12:09 AM, Owen Anderson <resistor at mac.com> wrote: > Hi Jingyue, > > Have you considered using dynamic uniformity checks? In my experience you > can

Alright, go ahead with it. —Owen > On Nov 17, 2014, at 4:58 AM, Daniil Troshkov <troshkovdanil at gmail.com> wrote: > > Hi! > > I have not found test case. (It is because we have no target using "ExpandInsertToVectorThroughStack"). > But I tested it for target currently not included in llvm trunk. > > This fix correct and trivial, so I'm offering

Hello, I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. - I am using the official release of LLVM 2.8 - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on

Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at

There is no __sync_synchronize or __sync_val_compare_and_swap on Mac OS X. One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 instead. The patch is attached. - xi -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1248 bytes Desc: not available URL:

What would you do with a just-hardware memory fence? If the compiler's free to move operations over the hardware fence, that seems to defeat the purpose. C++0X provides a compiler-only fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, section 29.8. On Sat, May 16, 2009 at

I detected this bug using test case from platform which is not currently supported on llvm targets. (Our team is porting llvm on new target). Creating the test case will take some extra time. I'll try to do it ASAP. Have you any ideas about the test case? (targets using ExpandInsertToVectorThroughStack, etc...) On Wed, Nov 12, 2014 at 8:29 PM, Owen Anderson <resistor at mac.com> wrote:

Hi owen, Can you please elaborate as to what should I do? Find all the instruction which have r2 in it and replace all of them with r1 and then remove the load instruction? Thanks Abhinav ----- Original Message ----- From: "Owen Anderson" <resistor at mac.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, November 14, 2008 11:22:32 PM

Many oveloaded intrinsics may be replaced with instructions - fabs or fma or sqrt. Chandler will probably explain the criteria. What the diff between fma and fadd? Or fptrunc and fabs? A new instruction like %a = loadm <4 x i32>* %addr, <4 x i32> %passthru, i32 4, <4 x i1>%mask is possible, but may be not very useful for most of targets. So we start from intrinsics. -

On May 23, 2009, at 9:41 PM, Xi Wang wrote: > There is no __sync_synchronize or __sync_val_compare_and_swap on Mac > OS X. One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 > instead. The patch is attached. Actually, __sync_synchronize and __sync_val_compare_and_swap DO exist on Darwin, but only if you use Apple's GCC 4.2 (or later), just as it is on Linux. We always

Some of you may have noticed that I addedd include/llvm/System/ Atomics.h to the repository briefly, which will be used for adding support for threading in LLVM. I have tried to provided appropriate implementations of the atomic ops (currently memory fence and CAS) for platforms we care about, but my knowledge of these, and my ability to test them, is limited. So, please, if you run on

On Jun 18, 2014, at 3:05 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Thu, Jun 19, 2014 at 8:29 AM, Owen Anderson <resistor at mac.com> wrote: > Numerical analysis is hard. Every numerics expert I have ever worked with considers trying to re-invent floating point a cardinal sin of numerical analysis. Just don’t do it. You will miss important considerations, and you will

we just follow a common recommendation to start with intrinsics: http://llvm.org/docs/ExtendingLLVM.html - Elena From: Owen Anderson [mailto:resistor at mac.com] Sent: Sunday, October 26, 2014 23:57 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu; dag at cray.com Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics What is the motivation for using intrinsics