similar to: [LLVMdev] Optimization on Atomics (and the OpenMP memory model)

Dear R-dev, I would like to accelerate my R computation by using parallel OpenMP compilers (e.g from Pathscale) on a 2-processor AMD server and I would like to know whether R is a tread safe library. The main kernel of the OpenMP parallelization is a C SEXP function that performs the computational routine in parallel with: ******************* SEXP example(SEXP list, SEXP expr, SEXP rho) {

Hi there I'm loking for a time-measurement to measure time-differences in milliseconds. On my search, I only found the following: - package "base": Sys.time() -> only second-accuracy - package "R.utils": System$currentTimeMillis() -> returns integer of milliseconds, but accuracy is only whole seconds too. At the moment I run every bit of code to measure

struct { volatile int flag; int value; } s; int get_value_when_ready() { while (s.flag) ; __sync_synchronize(); return s.value; } This is "valid" legacy code on some processors, yet it's not valid to replace __sync_synchronize with an atomic_thread_fence because, in theory, LLVM could hoist the load of s.value. In practice it currently doesn't, but it may in the

Ok, so the semantics of your fence would be that it's a volatile memory access (http://llvm.org/docs/LangRef.html#volatile-memory-accesses), and that it provides happens-before edges for volatile accesses in the same way that a seq_cst fence provides for atomic accesses. FWIW, I don't think we should add that, because it's an attempt to define behavior that's undefined for other

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

> 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

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

Hi, TL;DR: should we add a new memory ordering to fences? ``fence seq_cst`` is currently use to represent two things: - GCC-style builtin ``__sync_synchronize()`` [0][1]. - C11/C++11's sequentially-consistent thread fence ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. As far as I understand: - The former orders all memory and emits an actual fence instruction. - The

On 18 June 2013 15:27, Dmitri Rubinstein <dmitri.rubinstein at googlemail.com>wrote: > Is it possible to use PNaCl infrastructure (i.e. translation and execution > in a sandbox) without a Chrome ? > > I mean a something like a standalone VM like Java or Mono/C#. > Yes. The NaCl tool 'sel_ldr' will run a program inside a sandbox outside of the web browser. We do a

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

From the provided documentation I understood that in memory data structures of a PNaCl program are incompatible to the host program because ABIs are different (e.g. PNaCl pointers are always 32-bit even when running on x86_64 platform). So PNaCl program can't access any data structures of the host program directly. The only communication way is by using syscalls, but the document does not

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

2013/7/31 JF Bastien <jfb at google.com>: > Hi, > > TL;DR: should we add a new memory ordering to fences? > > > ``fence seq_cst`` is currently use to represent two things: > - GCC-style builtin ``__sync_synchronize()`` [0][1]. > - C11/C++11's sequentially-consistent thread fence > ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. > > As far

> 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 Fangrui, As you noted we are working on helping our NaCl users transition to WebAssembly and new web APIs that cover the functionality offered by NaCl. In terms of actually turning down the platform features, we recently announced a timeline at https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html. In terms of LLM, I would prefer to keep the support we have in the tree until

Hi all, LLVM/Clang supports an OS called 'NaCl' (llvm/include/llvm/ADT/Triple.h). It apparently hasn't had any development since 2015. This page https://developer.chrome.com/native-client/migration mentions that NaCl is deprecated. Is it still used? If not, I would propose that we remove it. I created a patch https://reviews.llvm.org/D78441 which I think can delete 90% of the

Hello, Following an earlier email ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html), we've published an initial version of the PNaCl bitcode reference manual online - http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl bitcode is a restricted subset of LLVM IR. The reference manual is quite terse, so for the bigger picture I'll repost links to the design

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >

> 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