similar to: [LLVMdev] Invalid STOREATOMIC Record

On Sat, Sep 17, 2011 at 1:00 PM, David Meyer <pdox at google.com> wrote: > The second equality here: (in lib/Bitcode/Reader/BitcodeReader.cpp) > >      AtomicOrdering Ordering = GetDecodedOrdering(Record[OpNum+2]); >      if (Ordering == NotAtomic || Ordering == Release || >          Ordering == AcquireRelease) >        return Error("Invalid STOREATOMIC record");

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

Problem LLVM's memory model for NonAtomic accesses is generally fairly weak, but explicitly disallows inserting stores that didn't occur in the original program.  This is required for any potentially shared location, but is overkill for any memory location which is provably only accessed by a single thread. My particular motivating example is a single thread private field in our

> } while (__c11_atomic_compare_exchange_weak( > addr, &oldval, newval, memory_order_seq_cst, memory_order_relaxed)); Actually, I think this condition is inverted. Should be "while (!_c11...". Sorry about that. Tim.

On Mon, Aug 22, 2011 at 7:35 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Mon, Aug 22, 2011 at 4:20 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>>> On

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting

Hello, As part of enhancing atomic operations in the ARM backend, we need to extend the Ops array in AtomicSDNode. This array is a private member of AtomicSDNode, so it's only accessible within 85 lines of code, none of which have anything to do with its size. Therefore, increasing the size of Ops shouldn't at all affect the behaviour of LLVM, we supposed. Much to our surprise, this

A question has come up on how to interpret the wording of LLVM's documentation regarding the possible memory ordering for success and failure of atomic compare_exchange operations. >From the LLVM reference: "The success and failure ordering <https://llvm.org/docs/LangRef.html#ordering> arguments specify how this cmpxchg synchronizes with other atomic operations. Both ordering

Hi all, We somewhat recently created/updated element-wise unordered-atomic versions of the memcpy, memmove, and memset memory intrinsics: Memcpy: https://reviews.llvm.org/rL305558 Memmove: https://reviews.llvm.org/rL307796 Memset: https://reviews.llvm.org/rL307854 These intrinsics are semantically similar to the regular versions. The main difference is that the underlying operation is performed

On Mon, Aug 22, 2011 at 4:20 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>>> On

On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte >>> <santosh.nagarakatte at gmail.com>

ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: $ llc -march arm -mtriple armv7-none-linux ... ParseARMTriple() will see TT == "arm-none-linux" instead of "armv7-none-linux". As a result, the

FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg flag to Clang. Applies against mainline. (As discussed, va_arg isn't really supported well so this probably doesn't work well on anything other than simple code, YMMV, etc) ~Will On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Have these changes made it to mainline? Is

Sergey, Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". (Note that this patch won't ever be part of llvm-gcc upstream. It will most likely be deprecated by later changes.) - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110220/f814866f/attachment.html>

On Mar 2, 2012, at 12:04 AM, David Meyer <pdox at google.com> wrote: > ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) > > In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: > > $ llc -march arm -mtriple armv7-none-linux ... > >

I've committed a fix: r149970. Please try it. I would really appreciate it if you can provide us with a test case (unreduced test case is fine). Evan On 2012 2 4, at 09:46, David Meyer <pdox at google.com> wrote: > Evan & llvmdev, > > I'm seeing a case where ARM Load/Store optimizer is breaking code. I have not had any luck trying to come up with a minimal example;

Evan & llvmdev, I'm seeing a case where ARM Load/Store optimizer is breaking code. I have not had any luck trying to come up with a minimal example; it is breaking in our stage 2 LLVM build. But here's what I'm seeing in the debug output: # Before ARMLoadStoreOptimizer: BB#21: derived from LLVM BB %cond.end Live Ins: %LR %R0 %R1 %R7 %R10 %R11 Predecessors according to

Have these changes made it to mainline? Is there a way to get a patch for the backend, which does the actual lowering? Thanks, Arushi On Sun, Feb 20, 2011 at 1:54 PM, David Meyer <pdox at google.com> wrote: > Sergey, > Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". > (Note that this patch won't ever be part of llvm-gcc upstream. It will most