similar to: [LLVMdev] Atomic memory barrier DAG representation

> Please prepare a patch for LangRef.html that explains what this thing > does :). What are all those bools? Once that is available I'll > review the rest of the llvm patch. http://llvm.org/releases/2.1/docs/LangRef.html#int_memory_barrier > In the call below, you don't have to pass in 4 i1's. Just passing in > the intrinsic ID should be fine. The type list is

On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: >> I'll take a hack at the front end support for >> __sync_synchronize after this goes in. > > This is the gcc side of the patch. Thanks for tackling this Andrew. Please prepare a patch for LangRef.html that explains what this thing does :). What

This looks good to me after a cursory scan, and seems to match what I had worked up with some very welcome better form on the codegen/backend side. =D I'm glad you've had some time to start hacking on this, it may be several more weeks before I get any time to work on these and other LLVM projects. Hopefully someone can chime in on appropriateness of the DAG and target

Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this

> GCC 4.2 compiles this to a no-op on x86: > > void foo() { > __sync_synchronize(); > } > > Are you seeing different behavior? What am I missing here? Maybe the processor does a memory barrier when it executes a call instruction. Ciao, Duncan.

On 7/12/07, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > Here are some comments, quotes are from the draft. > > > an operation based constraint cannot guard other operations > > I think constraints associated with a particular instruction usually apply > to this instruction and previous/subsequent instructions, so this wouldn't > be true. This is the

TableGen, as a DSL language, is made up of records. Every def corresponds to a record. For example, TableGen has a class Register, and your backend will define records by def GPR8 : Register<...>. You are correct in saying that the record definition is one of the SDNode values. These correspond 1:1 to llvm::ISD::NodeType

On Fri, Jan 29, 2016 at 11:39 AM, Rail Shafigulin <rail at esenciatech.com> wrote: > > > On Thu, Jan 28, 2016 at 8:34 PM, Dylan McKay <dylanmckay34 at gmail.com> > wrote: > >> Try visualising the DAG like this. >> >> ``` >> ---- GPR:$rA >> / >> set GPR:$rd ---- add >>

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Given the following definitions: def SDT_XSTGMVINI : SDTypeProfile<1, 1, [SDTCisInt<0>]>; def XSTGMVINI : SDNode<"XSTGISD::MVINI", SDT_XSTGMVINI>; def SDT_RELADDR : SDTypeProfile<1, 2, []>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; let Constraints = "$dst = $addr", Uses= [GRP] in

On Oct 7, 2008, at 12:04 PM, David Greene wrote: > On Friday 03 October 2008 12:06, Dan Gohman wrote: >> On Fri, October 3, 2008 9:10 am, David Greene wrote: >>> On Thursday 02 October 2008 19:32, Dan Gohman wrote: >>>> Looking at your dump() output above, it looks like the pre- >>>> selection >>>> loads have multiple uses, so even though

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

On Thu, Jan 28, 2016 at 8:34 PM, Dylan McKay <dylanmckay34 at gmail.com> wrote: > Try visualising the DAG like this. > > ``` > ---- GPR:$rA > / > set GPR:$rd ---- add > \ > ---- GPR:$rB > ``` > > Each instruction forms a DAG with its operands being subnodes. > >

On Friday 03 October 2008 12:06, Dan Gohman wrote: > On Fri, October 3, 2008 9:10 am, David Greene wrote: > > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection > >> loads have multiple uses, so even though you've managed to match a > >> larger pattern that incorporates them, they

On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > >smp_read_barrier_depends, smp_store_release and smp_load_acquire match > >the asm-generic variants exactly. Drop the local definitions and pull in > >asm-generic/barrier.h instead. >

I'm confused about how to specify DAG patterns for a given instruction Here is an example for my target class ALU1_RR<bits<4> subOp, string asmstr, SDNode OpNode> : ALU_RR<subOp, asmstr, [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 GPR:$rB)))]>; def ADD : ALU1_RR<0x0, "l.add", add>; The set operation simply creates a list. The add operation

On Tue, Apr 30, 2019 at 3:51 PM Przemyslaw Ossowski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > as I wrote in mu previous post I wanted to somehow mark one IR instruction > (in this particular case it would be 'load') during dedicated pass, which > will set the marking based on neighboring instructions. Next I wanted to > somehow to convey this marking

Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows

Hello, I’m looking for the best approach which would allow for marking given LLVM IR instruction during IR custom pass and later utilizing that information during DAG Instruction Selection in order to match given pattern based on this marking. I’m wondering if marking IR instruction utilizing Metadata is good idea. But how later pass that information to DAG and appropriately mark in