search for: volatiles

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

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

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;

...nalysis 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, accessing volatile memory via a non-volatile object results in an undefined behavior. This would suggest that volatiles and non-volatiles may be considered not to alias automatically, even if TBAA would not be able to prove it. The LLVM's code (on x86) at -O2 looks like this: .text .globl foo .align 16, 0x90 .type foo, at function foo:...

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

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 implies volatile? I guess it isn't, but I don't understand

I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this seems like an easy and simple deficiency in the IR intrinsic for memcpy. See below. On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison < arnaud.allarddegrandmaison at parrot.com> wrote: > define void @test(i16 zeroext %a) nounwind uwtable { > %r.sroa.0 = alloca i16, align 2 > %r.sroa.1 = alloca i16,

Hi Torok, >>> 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; >>> } >>>

...the following: a) Load registers into some LLVM IR registers (using inline asm) b) Modify the registers slightly c) Use volatile stores to save the registers into a stack-allocated area d) Context switch e) Use volatile loads to reload the registers from the stack-allocated area In this case, the volatiles are necessary; otherwise, the compiler (which knows nothing about the context switch code) may elide the stores to the stack memory (thinking it can keep state in processor registers), resulting in incorrect behavior. Now, while I've based this off of the Linux 2.4 kernel's context swi...

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 --------------

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) {

Le 08/01/2020 ? 09:18, Krzysztof Kozlowski a ?crit?: > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: >> >> Hi Krzysztof, >> >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote: >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk at kernel.org> wrote: >>>>

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>

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 =

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.

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

> 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

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)

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)