Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] Invalid STOREATOMIC Record"
2011 Sep 17
0
[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");
2014 Mar 07
3
[LLVMdev] [RFC] Add second "failure" AtomicOrdering to cmpxchg instruction
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
2018 Sep 14
5
RFC: Adding a !thread.private metadata
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
2015 Apr 24
2
[LLVMdev] Floating point atomic load and add
> } 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.
2011 Aug 23
1
[LLVMdev] LLVM Concurrency and Undef
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
2017 May 29
3
Should we split llvm Support and ADT?
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 May 29
3
Should we split llvm Support and ADT?
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 May 29
3
Should we split llvm Support and ADT?
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
2013 Aug 23
1
[LLVMdev] Incredible effects of extending AtomicSDNode::Ops
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
2020 Apr 04
2
Permitted success/failure orderings for atomic compare_exchange
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
2017 Aug 17
3
[RFC] Injecting new element atomic memory intrinsics into MemIntrinsic class hierarchy
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
2011 Aug 22
0
[LLVMdev] LLVM Concurrency and Undef
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
2011 Aug 22
2
[LLVMdev] LLVM Concurrency and Undef
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>
2012 Mar 02
2
[LLVMdev] "-march" trashing ARM triple
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
2011 Aug 17
2
[LLVMdev] Is va_arg deprecated?
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
2011 Feb 20
2
[LLVMdev] Is va_arg deprecated?
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>
2012 Mar 02
0
[LLVMdev] "-march" trashing ARM triple
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 ...
>
>
2012 Feb 07
0
[LLVMdev] ARMLoadStoreOptimizer bug
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;
2012 Feb 04
4
[LLVMdev] ARMLoadStoreOptimizer bug
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
2011 May 12
0
[LLVMdev] Is va_arg deprecated?
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