search for: volatile

Hi all, >> I think that this is the right way to approach this: we should change >> MemorySSA to be less conservative in this regard. LLVM's language reference is >> pretty explicit about reordering volatile and non-volatile operations: >> >>> The optimizers must not change the number of volatile operations or change >>> their order of execution relative to other volatile operations. The >>> optimizers /may/ change the order of volatile operations relative to >>&g...

...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 best > not to exploit this ambiguity at the moment by unconditionally > allowing the motion of nonvolatile loads above volatile loads (and > vice versa)" > So the testcase: test/Analysis/MemorySSA/volatile-...

On Wed, Sep 4, 2013 at 2:33 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org > wrote: > A customer has reported a performance problem, which I have eventually > tracked down to the following situation: > > Consider this program: > > int foo(int *p, volatile int *q, int n) { > int i, s = 0; > for (i = 0; i < n; ++i) > s += *p + *q; > return s; > } > > > LLVM's analysis indicates that *p and *q can alias, even though *p is > non-volatile whereas *q is volatile. I don't have the exact section from > the...

A customer has reported a performance problem, which I have eventually tracked down to the following situation: Consider this program: int foo(int *p, volatile int *q, int n) { int i, s = 0; for (i = 0; i < n; ++i) s += *p + *q; return s; } LLVM's analysis indicates that *p and *q can alias, even though *p is non-volatile whereas *q is volatile. I don't have the exact section from the C standard, but if I remember correctly,...

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 to treat volatile loads and stores essentially...

Hi llvm-dev, I read about volatile and atomic modifiers in the docs[1], and I feel they make sense to me individually. However, I noticed that store[2] and load[3] instructions can be marked as both volatile and atomic. What's the use case for using both volatile and atomic on an instruction? Isn't it the case that atomic i...

...arddegrandmaison at parrot.com> wrote: > define void @test(i16 zeroext %a) nounwind uwtable { > %r.sroa.0 = alloca i16, align 2 > %r.sroa.1 = alloca i16, align 2 > store i16 %a, i16* %r.sroa.0, align 2 > store i16 1, i16* %r.sroa.1, align 2 > %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2 > store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), > align 32 > %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2 > store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), > align 2 > Just so we're on...

...; Well...strictly as LLVM IR I find externally visible incorrect >>> behavior unlikely, it's just a "different definition". For C and >>> C++, I'd be looking at more complicated variations of >>> >>> int main() >>> { >>> volatile int i = 1; >>> return 0; >>> } >>> >>> It's clear that the LLVM IR representation of i cannot be simply >>> IR-volatile qualified, as that load gets optimized out while C and >>> C++ won't optimize it out. I'd *hope* that Drag...

...IR I find externally visible incorrect >>>> behavior unlikely, it's just a "different definition". For C and >>>> C++, I'd be looking at more complicated variations of >>>> >>>> int main() >>>> { >>>> volatile int i = 1; >>>> return 0; >>>> } >>>> >>>> It's clear that the LLVM IR representation of i cannot be simply >>>> IR-volatile qualified, as that load gets optimized out while C and >>>> C++ won't optimize it out....

The attached file contains some simple functions that manipulate volatile varibles. The functions near the top of the file should turn into code that loads from x and then stores to it. The LLVM version on the web (not sure if it's the latest...) gets most of these wrong. John Regehr -------------- next part -------------- //////////////////////////////////////...

...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) { struct R r = { a, 1 }; *addr = r; } $ clang -O2 -o - -emit-llvm -S -c test.c ; ModuleID = 'test.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:...

...inconsistent interface among the >>>> architectures: some taking address as const, some not. >>>> >>>> It seems there is nothing really stopping all of them to take >>>> pointer to const. >>> >>> Shouldn't all of them take const volatile __iomem pointers? >>> It seems the "volatile" is missing from all but the implementations in >>> include/asm-generic/io.h. >> >> As my "volatile" comment applies to iowrite*(), too, probably that should be >> done in a separate patch. >>...

Hi Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina ----...

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> struct R { uint16_t a; uint16_t b; }; volatile struct...

So, i'm working through the last of miniscule gvn optimizations, and one of the things that gets tested is whether it will eliminate non-volatile loads in favor of ohter non-volatile loads when there are volatile loads in the way. I.E. define i32 @test1(i32* nocapture %p, i32* nocapture %q) { entry: %x = load i32, i32* %p %0 = load volatile i32, i32* %q %y = load i32, i32* %p %add = sub i32 %y, %x ret i32 %add } Currently, getM...

The primary reason I don’t want to provide any guarantees for what instructions are used to implement volatile memcpy is that it would forbid lowering a volatile memcpy to a library call. clang uses a volatile memcpy for struct assignment in C. For example, “void f(volatile struct S*p) { p[0] = p[1]; }”. It’s not really that useful, but it’s been done that way since before clang was written. -Eli From:...

I've got a question about how SelectionDAGBuilder treats loads. The LLVM Language Reference Manual explicitly states that the order of volatile operations may be changed relative to non-volatile operations. However, when the SelectionDAGBuilder in LLVM 3.1 encounters a volatile load, it flushes all pending loads and then chains the volatile load onto them meaning that the volatile load must be scheduled after those loads. While this behavi...

> On Jun 12, 2019, at 9:38 PM, James Y Knight <jyknight at google.com> wrote: > >  >> On Tue, Jun 11, 2019 at 12:08 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> I think we want option 2.: keep volatile memcpy, and implement it as touching each byte exactly once. That’s unlikely to be particularly useful for every direct-to-hardware uses, but it behaves intuitively enough that I think it’s desirable. > > As Eli pointed out, that precludes lowering a volatile memcpy into a call the memcpy li...

On Thu, Jul 2, 2020 at 11:48 AM Will Deacon <will at kernel.org> wrote: > On Thu, Jul 02, 2020 at 10:32:39AM +0100, Mark Rutland wrote: > > On Tue, Jun 30, 2020 at 06:37:20PM +0100, Will Deacon wrote: > > > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > > > +#define __smp_load_acquire(p) \ > > > +({ \ > > > + __unqual_scalar_typeof(*p) ___p1 =...

On Thu, Jul 2, 2020 at 11:48 AM Will Deacon <will at kernel.org> wrote: > On Thu, Jul 02, 2020 at 10:32:39AM +0100, Mark Rutland wrote: > > On Tue, Jun 30, 2020 at 06:37:20PM +0100, Will Deacon wrote: > > > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > > > +#define __smp_load_acquire(p) \ > > > +({ \ > > > + __unqual_scalar_typeof(*p) ___p1 =...