search for: membar

Dear all, Let's say there is some complex tblgen intrinsic definition, for example: class MEMBAR<string StrOp, Intrinsic IntOP> : NVPTXInst<(outs), (ins), StrOp, [(IntOP)]>; def INT_MEMBAR_CTA : MEMBAR<"membar.cta;", int_nvvm_membar_cta>; def INT_MEMBAR_GL : MEMBAR<"membar.gl;", int_nvvm_membar_gl>; def INT_MEMBAR_SYS : M...

...ous current LLVM architectures and > > summarized what he found. What he found are the memory barriers that the > > various processors support. > > What you would want is to have a model that is (1) easy-to-use for the > developers and (2) close to what the hardware offers. L/S membars are easy to > use, but I think some architectures such as Itanium offer different membars > with different costs. So if you pick the wrong model and have to use stronger > membars (mfence Itanium) to implement your model, than you pay for that by > decreased performance. Itanium was t...

...looked at what the various current LLVM architectures and > summarized what he found. What he found are the memory barriers that the > various processors support. What you would want is to have a model that is (1) easy-to-use for the developers and (2) close to what the hardware offers. L/S membars are easy to use, but I think some architectures such as Itanium offer different membars with different costs. So if you pick the wrong model and have to use stronger membars (mfence Itanium) to implement your model, than you pay for that by decreased performance. > > > Did you have a...

...need to specify that the LLVM volatile keyword can be added to the atomic operations to prevent optimizations from modifying or removing them. I'm not aware of any optimization that works on atomic ops in practice, but I don't see why they couldn't be written. 5) With the addition of membar instructions, it may be time to re-think what the LLVM volatile keyword means. Currently, volatile prevents removing, modifying, or reordering of a load or store. However, membar also prevents reordering. Perhaps it would be useful to redefine volatile to mean that a load/store cannot be removed...

Torvald Riegel wrote: > Hi, > > I'd like to see support for something like this. I have some comments, and I > think there is existing work that you can reuse. "reuse within the compiler." > "While the processor may spin and attempt the atomic operation more than once > before it is successful, research indicates this is extremely uncommon." > I

Hello, After a fair amount of research and work, I have put together a concrete proposal for LLVM representations of atomic operations and synchronization constructs. These aim to provide the minimal functionality in the IR for representing the hardware constructs that threading libraries and parallel programming rely on. http://chandlerc.net/llvm_atomics.html While I am no expert on the

...TAS a byte is sufficient, whereas with swap you probably would require that the exchange has machine-word size. > These implementations assume a very conservative interpretation. > result = __sync_fetch_and_add( <ty>* ptr, <ty> value ) > call void @llvm.atomic.membarrier( i1 true, i1 true, i1 true, > i1 true ) > %result = call <ty> @llvm.atomic.las( <ty>* %ptr, <ty> %value ) Shouldn't you have a second membar after the las() to be very conservative (i.e., if las() is supposed to really be linearizable)? Otherwise,...

...an unnecessary dependency, in my personal and not so humble opinion. > Second, I guess there has been some serious effort put into selecting the > specific model. So, for example, if you look at some of Hans' published > slides etc., there are some arguments in favor of associating membars with > specific instructions. Do you know reasons why LLVM shouldn't do this? You mean the papers that don't have to do with garbage collection? :-) Seriously, I think that's the overall purpose for some of this work so that llvm can do a better job in instruction-level paralleli...

...move them when those semantics allowed it... specifically, constant propagation should be able to replace the values in these operations with constants if it can do so, no? Perhaps I don't understand what situation you're trying to avoid/prepare for with this. > 5) With the addition of membar instructions, it may be time to re-think > what the LLVM volatile keyword means. Currently, volatile prevents > removing, modifying, or reordering of a load or store. However, membar > also prevents reordering. Perhaps it would be useful to redefine > volatile to mean that a load/sto...

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

...ese operations. 'cas' and 'swap' will lower to single byte instructions on x86 f.ex. > > These implementations assume a very conservative interpretation. > > result = __sync_fetch_and_add( <ty>* ptr, <ty> value ) > > call void @llvm.atomic.membarrier( i1 true, i1 true, i1 true, > > i1 true ) > > %result = call <ty> @llvm.atomic.las( <ty>* %ptr, <ty> %value ) > > Shouldn't you have a second membar after the las() to be very conservative > (i.e., if las() is supposed to really be line...

...ps seems to have (basic?) support for Alpha). > > Second, I guess there has been some serious effort put into selecting > > the specific model. So, for example, if you look at some of Hans' > > published slides etc., there are some arguments in favor of associating > > membars with specific instructions. Do you know reasons why LLVM > > shouldn't do this? > > You mean the papers that don't have to do with garbage collection? :-) > > Seriously, I think that's the overall purpose for some of this work so > that llvm can do a better job in...

...are really > > just a very few primitives we need from which higher order things can be > > constructed. One is a memory barrier to ensure cache is flushed, etc. so > > we can be certain a write to memory has "taken". > > Just out of curiousity, what do you need a membar for? The only thing > that I'm aware of it being useful for (besides implementing threading > packages) are Read-Copy-Update algorithms. Um, to implement a threading package :) I have assumed that, true to its name, LLVM will only provide the lowest level primitives needed to implement...

...will become LLVM intrinsics. </shameless plug> <technical aside> The difficult part of an OS is not actually all the funky hardware stuff. The intrinsics for those are actually very straightforward and easy to implement. I/O, for example, is really volatile loads and stores with MEMBAR's. Registering interrupt handlers takes some very straitforward intrinsics. The I/O intrinsics are already implemented for LLVM in the x86 code generator (minus the FENCE/MEMBAR instructions). The difficult part is the code of the OS that changes native hardware state. The kernel's c...

...omicFence 0x85fd8d8, 0x85c7890, 0x85dd9e8 [ORD=4] [ID=27]example.c:378:13 0x85c7890: i64 = Constant<7> [ID=5]example.c:378:13 0x85dd9e8: i64 = Constant<1> [ID=6]example.c:378:13 I believe it should be equivalent to "__threadfence()" in CUDA and "call void @llvm.nvvm.membar.gl()" in LLVM-IR. However, I am not sure where to locate the fix. Any ideas ? Bests regards, Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/95c70369/attachment.html>

...roc/iomem output and/or lspci listing from the host to see how this > > works would be useful. > Correct. So MMU not IOMMU. > > In the guest kernel, the bridges and devices in the VMD domain are > programmed with the addresses provided in the VMD endpoint's BAR2&4 > (MEMBAR1&2). Because these BARs are populated with guest addresses, MMU > translates to host physical and the bridge window rejects MMIO not in > its [GPA] range. > > As an example: > Host: > 94000000-97ffffff : 0000:17:05.5 > 94000000-97ffffff : VMD MEMBAR1 > 94000...

...is needed. I think there are really > just a very few primitives we need from which higher order things can be > constructed. One is a memory barrier to ensure cache is flushed, etc. so > we can be certain a write to memory has "taken". Just out of curiousity, what do you need a membar for? The only thing that I'm aware of it being useful for (besides implementing threading packages) are Read-Copy-Update algorithms. > This goes beyond the current volatile support and will need to access > specific machine instructions if a native barrier is supported. Another > is...

In order to get to the next stage with LLVM (like compiling a kernel) we need to allow "pass through" of inline assembly so things like device drivers, interrupt vectors, etc. can be written. While this feature breaks the "pure" LLVM IR, I don't see any way around it. So, I thought I'd bring it up here so we can discuss potential implementations. I think we should

A while back I promised to provide some feedback on useful extensions to LLVM to better support source language writers (i.e. those _using_ LLVM, not developing it). Below is a list of the ideas I've come up with so far. As I get more of XPL's compiler done, I'll start diving into each of the these areas. I'm posting early in the hopes that discussion will bear some fruit. In

...t using its code is very unlikely. >>> Second, I guess there has been some serious effort put into selecting >>> the specific model. So, for example, if you look at some of Hans' >>> published slides etc., there are some arguments in favor of associating >>> membars with specific instructions. Do you know reasons why LLVM >>> shouldn't do this? >> You mean the papers that don't have to do with garbage collection? :-) >> >> Seriously, I think that's the overall purpose for some of this work so >> that llvm can do a...