similar to: Possibility of implementing a low-level naive lock purely with LLVM atomics?

I submitted the problem report to clang's bugzilla but no one seems to care so I have to send it to the mailing list. clang 3.7 svn (trunk 229055 as the time I was to report this problem) generates slower code than 3.5 (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)) for the following code. It is a "8 queens puzzle" solver written as an educational example. As

The regressions in the performance of generated code, introduced by the llvm 3.6 release, don't seem to be limited to this 8 queens puzzle" solver test case. See... http://www.phoronix.com/scan.php?page=article&item=llvm-clang-3.5-3.6-rc1&num=1 where a bit hit in the performance of the Sparse Matrix Multiply test of the SciMark v2.0 benchmark was observed as well as others.

Using the SciMark 2.0 code from http://math.nist.gov/scimark2/scimark2_1c.zip compiled with the same... make CFLAGS="-O3 -march=native" I am able to reproduce the 22% performance regression in the run time of the Sparse matmult benchmark. For 10 runs of the scimark2 benechmark, I get 998.439+/-0.4828 with the release llvm clang 3.5.1 compiler and 1217.363+/-1.1004 for the current

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

On Mon, Oct 31, 2011 at 3:15 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu>wrote: > I notice that there is not currently any intrinsic support for atomics in > the PTX backend. Is this on the roadmap? Should it be as easy to add as it > seems (plumbing through just like the thread ID instructions, &c.)? The > obvious difference is that these ops have side effects. > It

I notice that there is not currently any intrinsic support for atomics in the PTX backend. Is this on the roadmap? Should it be as easy to add as it seems (plumbing through just like the thread ID instructions, &c.)? The obvious difference is that these ops have side effects. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type:

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

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

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

# RFC: Atomic LL/SC loops in LLVM revisited ## Summary This proposal gives a brief overview of the challenges of lowering to LL/SC loops and details the approach I am taking for RISC-V. Beyond getting feedback on that work, my intention is to find consensus on moving other backends towards a similar approach and sharing common code where feasible. Scroll down to 'Questions' for a summary

I am using GLM to calculate logit models based on cross-sectional data. I am now down to the hard work of making the results intelligible to very average readers. Is there any way to calculate a psuedo analoque to the R^2 in standard linear regression for use as a purely descriptive statistic of goodness of fit? Most of the readers of my report will be vaguely familiar and more comfortable with

Hi, There's several, to my eyes, somewhat related looking bugs: Bug 36743 - Cannot select: X86ISD::CALL ICE with -mx32 -O2 -fno-plt https://bugs.llvm.org/show_bug.cgi?id=36743 Bug 34268 - JITting of x32 code on x64 fails with crash or instruction selection error. https://bugs.llvm.org/show_bug.cgi?id=34268 There's unfortunately been no investigation. I'm asking because I hit

On 12/11/2015 12:05 AM, JF Bastien wrote: > On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, we limit atomic loads and stores to either pointer or > integer types. I would like to propose that we extend this to > allow both floating point and vector types

Hi All, The 2020 Virtual LLVM Developer's Meeting is coming up the week after next. I'll be hosting a JIT Birds-of-a-Feather session on Thursday the 8th at 10:55am PDT (See http://llvm.org/devmtg/2020-09/schedule/). I'm planning to run this more like a Round Table: Minimal introduction, plenty of time for discussion. Does anyone have any LLVM JIT related topics that they would

Hi, On 2020-09-25 16:38:41 -0700, Andres Freund via llvm-dev wrote: > On 2020-09-24 16:34:30 -0700, Lang Hames wrote: > > If anyone wants to check out the OrcV1 removal branch and provide feedback > > now is the time. Otherwise I will aim to land the work in the mainline > > early next week. > > I'm trying to get it to work with postgres. Unfortunately this week

On 05/05/18 17:58, Andres Freund wrote: > You're building LLVM with assertions enabled > (-DLLVM_ENABLE_ASSERTIONS=ON). > Some of those are fairly expensive... > Is there another way to get LLVM to check the correctness of my IR without the assertions? That's what I'm assuming I need the flag for (it's been a long time since I experimented with it) If there is no way

Andres: FWIW, codegen will do the merge if you turn on global alias analysis for it "-combiner-global-alias-analysis". That said, we should be able to do this merging earlier. -Nirav On Mon, Sep 10, 2018 at 8:33 PM, Andres Freund via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 2018-09-10 13:42:21 -0700, Andres Freund wrote: > > I have, in postres,

Hi Andres, A topic that I'd find interesting is what it'd take to make it easier to > use profile guided optimization in the context of JIT. A few years back > I crudely hacked this together, but it was fairly ugly. It'd be nice to > make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and

Forgive me if I'm missing something obvious, but it seems that a number of core instructions—I'm specifically running in to `atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be constructed from the C bindings, and are therefore also inaccessible to the OCaml bindings. There are opcodes for each of these in the llvm-c/Core.h, but there seems to be no way to construct them. Is there

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the