similar to: [LLVMdev] Are x86/ARM likely to support atomics larger than 2 pointers?

I keep running up against the same error when I try to plot a line from a nls model. The data is fisheries length/weight data. Code follows: require(graphics) pow = nls(Weight~alpha*Length^beta, data=wae, start=list(alpha=0.0000001, beta=3.0), trace=TRUE) predict(pow) plot(Weight~Length,

I don't have much of substance to add, but I will say that I like the proposal (I too prefer Alternative A). When adding C11 atomic support for hexagon, I found it surprising that support for the __sync_* was implemented completely differently than the C11 atomics. On 1/27/2016 1:55 PM, James Knight via llvm-dev wrote: > Right now, the atomics implementation in clang is a bit of a

Right now, the atomics implementation in clang is a bit of a mess. It has three basically completely distinct code-paths: There's the legacy __sync_* builtins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for

----- Original Message ----- > From: "Ben via llvm-dev Craig" <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Sent: Thursday, January 28, 2016 9:41:06 AM > Subject: Re: [llvm-dev] Adding sanity to the Atomics implementation > > > I don't have much of substance to add, but I will say that I like the > proposal (I too prefer Alternative

All - I have a number of rows that I am assigning length classes to via l.class<-with(wae, ifelse((Length>=120)&(Length<130),"125", ifelse((Length>=130)&(Length<140),"135", ifelse((Length>=140)&(Length<150),"145", ifelse((Length>=150)&(Length<160),"155",

Hi, I think this more of a front-end issue than a compile-rt issue, but I’m also copying the llvm-dev list In compiler-rt the file lib/builtins/atomic.c seems to rely on determining at compile time if an atomic operation of size 1, 2, 4, or 8 is always lock free. For example, in the implementation of __atomic_load_8() we have something like this after macro expansion: void __atomic_load_8(…) {

Testing for __STDC_CONSTANT_MACROS has the advantage that you are forced to define __STDC_CONSTANT_MACROS on win32. If you then switch to another platform the project still compiles. -Jochen

Hi All, I am reading about LLVM IR atomics (http://llvm.org/docs/Atomics.html) and get confused about the difference between "Unordered" and "Monotonic". In particular, I am not sure I understand the statement of "It essentially guarantees that if you take all the operations affecting a specific address, a consistent ordering exists.". For me, it means that for the

On May 16, 2009, at 10:01 PM, Owen Anderson wrote: > OK, I've enhanced Atomic.h by pulling in a bunch of implementations > from libatomic_ops, and others that I could figure out on my own. > > Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME > PATCHES IF IT DOESN'T WORK! Similarly, if you think the > implementation could be improved for your

OK, I've enhanced Atomic.h by pulling in a bunch of implementations from libatomic_ops, and others that I could figure out on my own. Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME PATCHES IF IT DOESN'T WORK! Similarly, if you think the implementation could be improved for your platform, send me a patch. I know that Sparc doesn't work currently (no CAS

On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided

Greetings everyone, I am working on Aarch64 LSE out-of-line atomics support in LLVM, porting this GCC series: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01034.html After local design experiments I've got some questions about upstream-suitable ways of implementation. More specifically: 1. Pass to expand atomics to library helper functions calls. These helpers test for the presence

On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. Are they macros or functions? If macros, why not just #undef them at the top of Atomics.h? -Chris > > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the reasonable

On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote: > I think Clang should continue to duplicate this information, the same way > we duplicate target datalayout strings. Other than that, sure, we can let > LLVM expand IR operations to libcalls. I don't immediately see a problem > with that. Note that a libcall doesn't necessarily mean using locks. With

Identified a while before the release, there is an issue with 64-bit atomics on ARM that was making Clang mis-compile a lot of code, including Clang itself. http://llvm.org/bugs/show_bug.cgi?id=15429 Attached is a patch proposed by Benjamin with the corrections to the test. I'm not an expert on how Clang lowers C11 atomics, but the resulting IR seems correct, and after self-hosting Clang

Hello everyone, I have recently started on optimizing C11/C++11 atomics in LLVM, and plan to focus on that for the next two months as an intern in the PNaCl team. I’ve sent two patches on this topic to Phabricator that fix http://llvm.org/bugs/show_bug.cgi?id=17281: http://reviews.llvm.org/D4796 http://reviews.llvm.org/D4797 The first patch is X86-specific, and tries to apply operations with

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

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 mac.com> wrote: > 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

Looking further during down time at the dev meeting today, it actually seems that PTX atom.* and red.* intrinsics map extremely naturally onto the LLVM atomicrmw and cmpxchg instructions. The biggest issue is that a subset of things expressible with these LLVM instructions do not trivially map to PTX, and the range of things naturally supported depends on the features of a given target. With

Owen Anderson wrote: > 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. Just out of curiosity, is there a design document somewhere for the plan for threading? Also, atomic ops are usually pretty low level things used for nonblocking algorithms or to build higher level