similar to: [LLVMdev] Plan to optimize atomics in LLVM

> I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass) > that just share some of the code This would more normally be done via target hooks in LLVM, though the principle is sound. > But it must be target-dependent as for example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per

> Longer term, I hope to improve the fence elimination of the ARM backend with > a kind of PRE algorithm. Both of these improvements to the ARM backend > should be fairly straightforward to port to the POWER architecture later, > and I hope to also do that. > > Any reason these couldn't be done at the IR level? I definitely agree here. At the time, it was a plausible idea

Hi everyone, The OpenMP standards committee has begun work to formalize their memory model, and define its relationship to the C/C++ memory models. A questionnaire has been put together (pasted below), and I'd like everyone's help in composing detailed answers to inform their decision-making process. While our OpenMP support is still in active development, many of these questions apply

> From my reading of Atomics.rst, it would be sound to reorder (It does not > say much about load-linked, so I am treating it as a normal load here) > >> store seq_cst >> fence release >> load-linked monotonic > > into > >> load-linked monotonic >> store seq_cst >> fence release > Which would make an execution ending in %old_x = %old_y = 0

Hi Robin, On 15 August 2014 21:49, Robin Morisset <morisset at google.com> wrote: > I have > attached the corresponding patches; they are not completely ready for review > (mostly missing tests), I would just like to make sure that the general > approach seems reasonable. I've had a quick glance at the patches, and the code seems fairly sane. But I'm not so sure about

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

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

----- 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

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

Hi Rafael, As you mentioned in the bug, we should only apply this change when hard-float is set, which it is by default on armv7a, I presume. >From that part of the code, I can infer that by the time "MaxAtomicPromoteWidth = 64;", the variable SoftFloat is not properly set, so a simple "if (!SoftFloat)" won't cut in there. It seems SoftFloat is being set on

Hi Philip, > Aside: From the documentation, it's actually unclear how strong a barrier > ISB actually is. The "fetched after the ISB" gives a lot of room for > interpretation. (i.e. is it legal for a cpu to fetch every instruction in a > function, queue them for execution under wait conditions, *then* fetch the > ISB? This would be a *really* weird implementation,

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

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

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

There's a discussion over on cfe-commits about how future-proof to make the C1x/C++11 atomic ABI. (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20111010/047647.html) One argument is that, because C ABI changes are painful, and processors may introduce larger atomic operations in the future, we should try to design the atomics implementation in such a way that it can take

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

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

Hello people. My name is Rub?n. Firts, excuse me for my bad english. I run Debian 6.0.6, kernel 2.6.32-5-amd64 in my machine. I bought a ISB Sola basic UPS, model Micro SR inet, with usb conection. I Configure the nut.conf file in standalone mode and I install de isbmex driver. The ups.conf: [ISB_sola-basic] driver = isbmex port = auto With de command upsdrvctl start the

I've already fixed the bugs, but as with the last one, this is not critical enough to allow breaking current R-devel's code freeze. I hope I will have corrected it for 1.5.1.. ## Here is code reproducing the problems; ## I use try(.) whenever I know the current versions of R would ## give an error: library(splines) x <- c(1:3,5:6) y <- c(3:1,5:6) (isP <- interpSpline(x,y))#