search for: membars

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 :

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

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

Chandler Carruth wrote: > 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. > >

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

...linearizable)? Otherwise, the effects of the las() can be reordered with respect to effects of subsequent instructions. This also shows that you get additional overhead in the codegen if barriers are not associated with an operation: To emit efficient code, codegen would have to check whether membars are next to an operation, and whether they can be merged with the operation. If codegens don't do it, then runtime overhead will be higher due to the unnecessary barriers. This also implies that there is no reordering of las() with other operations until codegen phase, so you would at least...

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

On 7/9/07, John Criswell <criswell at cs.uiuc.edu> wrote: > 1) You may want to consider adding atomic load-<bitwise operation>-store > instructions in addition to load-<add/subtract> instructions. The Linux > kernel uses these for atomic bit setting/clearing, and on many systems > they can be implemented more efficiently using special assembly > instructions.

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

...to move to what I think are more appropriate for the instructions, rather than trusting their descriptions. > This also shows that you get additional overhead in the codegen if barriers > are not associated with an operation: To emit efficient code, codegen would > have to check whether membars are next to an operation, and whether they > can be merged with the operation. If codegens don't do it, then runtime > overhead will be higher due to the unnecessary barriers. This also implies > that there is no reordering of las() with other operations until codegen > phase, so yo...

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

On Wed, 2004-01-07 at 11:12, Chris Lattner wrote: > > ------------------------------------------------------------------ > > 1. Definition Import > > Source languages are likely to create lots of named type and value > > definitions for the memory objects the language manipulates. Redefining > > these in every module produces byte code bloat. It would be very useful

Reid Spencer wrote: > 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. <shameless plug> Actually, there should be a way around it.

Hi, I get this error when compiling a code that contains "__sync_synchronize()" fatal error: error in backend: Cannot select: 0x85ddfb0: ch = AtomicFence 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

...> + data = g_malloc0(sizeof(*data)); > > > + ret = pread(vdev->vbasedev.fd, data->membar_phys, 16, > > > + vdev->config_offset + PCI_BASE_ADDRESS_2); > > > + if (ret != 16) { > > > + error_report("VMD %s cannot read MEMBARs (%d)", > > > + vdev->vbasedev.name, ret); > > > + g_free(data); > > > + return -EFAULT; > > > + } > > > + > > > + quirk = vfio_quirk_alloc(1); > > > + quirk->data = data; > > &...

On Tue, 6 Jan 2004, Reid Spencer wrote: > 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. Cool! Ideas are alway welcome! > If you respond to this, please respond to each item in a separate >

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