similar to: [LLVMdev] why are volatile memory accesses ordered?

Dunno whether it's worthwhile, but we definitely test for it, and if his two non-volatile loads were identical, we'd definitely eliminate them in GVN. On Thu, Apr 2, 2015 at 6:09 PM, Chandler Carruth <chandlerc at google.com> wrote: > Could you explain why you think it is worthwhile to optimize code involving > a volatile access? > > On Thu, Apr 2, 2015 at 6:08 PM

Daniel, Thanks a lot for the pointer, that's very helpful! I'll use that as a guide to update how we handle volatile accesses. Mind if I ask for feedback when I update the patch? Krzysztof, Thanks for the answer, that was very informative! I appreciate it! Best, Alina On Wed, Dec 20, 2017 at 5:33 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Hi Alina, > The

On 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

Greetings all, I am picking up the work that was started in https://reviews.llvm.org/D27133 — adding support for an element-atomic memcpy/memset/memmove to LLVM. I would appreciate suggestions/thoughts/advice/comments on how to best proceed with this work in a way that will be acceptable to the LLVM group. I apologize in advance; this is going to be a long one... **Background** Loads/stores

Hi All, Using clang+llvm at head, I noticed a weird behaviour with the following reduced testcase : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) { struct R r = { a, 1 }; *addr = r; } $ clang -O2 -o - -emit-llvm -S -c test.c ; ModuleID = 'test.c' target

Hello. This might be a trivial question, but is it correct if the signal handler aborts the program? For example: int *normal = ADDRESS1; volatile int* ptr = ADDRESS2; int k = *ptr; // segfaults, and the signal handler calls abort() int value = *normal; // this may be UB(undefined behavior). Let's assume that normal is dereferenceable if ptr1 does not raise SEGSEGV, but accessing

Hi Sanjoy, Responses inlined… > On May 8, 2017, at 12:49 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Daniel, > > [+CC Mehdi, Vedant for the auto upgrade issue] > > On Mon, May 8, 2017 at 7:54 AM, Daniel Neilson via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> **Method** >> >> Clearly we are going to have to teach

On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote: > +Philip to get his input too. > I've talked with George offline, and here's a summary: > > In D16875 <https://reviews.llvm.org/D16875>, the decision made was: > "The LLVM spec is ambiguous about whether we can hoist a non-volatile > load above a volatile load when the loads alias. It's probably

The fact two IR values are defined the same way doesn't necessarily imply they are actually the same value. e.g. %a = load volatile i32, i32* %p %b = load volatile i32, i32* %p As Sanjoy said, though, it should always be legal to optimize all uses of different "freeze(%x)" values to use the same def - this is equivalent to choosing the same value for all freezes. It's just not

Hi All, In the language reference manual, the access behavior of the memcpy, memmove and memset intrinsics is not well defined with respect to the volatile flag. The LRM even states that "it is unwise to depend on it". This forces optimization passes to be conservatively correct and prevent optimizations. A very simple example of this is : $ cat test.c #include <stdint.h>

I can't think of a better way to do this, so I think it's ok. I also submitted a complementary patch on llvm-commits clarifying volatile semantics. -Andy On Jan 28, 2013, at 8:54 AM, Arnaud A. de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi All, > > In the language reference manual, the access behavior of the memcpy, > memmove and memset

Hi everyone, I am using the dragonegg plugin to produce bitcode for the following small C program: int main() { 1: int x = -5; 2: x = 6; 3: return 0; } The assignments on lines 1 and 2 are removed even when no optimization flags are specified. I tried making variable "x" volatile, which prevents the assignments from being removed, however I am no longer able to recover the original

As a results of my investigations, the thread is also added to cfe-dev. The context : while porting my company code from the LLVM/Clang releases 3.1 to 3.2, I stumbled on a code size and performance regression. The testcase is : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) {

On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > However, I didn't quite understand your point about may-throw -- how > > is may-throw different from a generic side-effect (volatile store, > > syscall etc.)? All of those can't be hoisted or sunk -- we have to >

Here's a fun spin on this same topic (I can't file a bug at this moment since llvm.org is down). Consider: define i32 @x(i32* %x, i1* %y) { entry: br label %loop loop: %v = phi i32 [ 0 , %entry ], [ %v.inc, %exit.inner ], [ %v, %loop ] %c = load volatile i1, i1* %y br i1 %c, label %exit.inner, label %loop exit.inner: %c1 = load volatile i1, i1* %y %x.val = load i32, i32*

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

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

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

Hi Sanjoy, Response/thoughts below... On Aug 19, 2017, at 3:13 PM, Sanjoy Das <sanjoy at playingwithpointers.com<mailto:sanjoy at playingwithpointers.com>> wrote: Hi Daniel, On Thu, Aug 17, 2017 at 8:32 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Cons: One more attribute to check when implementing a pass that

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >