search for: atomicrmwinst

In the implementation of the AliasSetTracker, I see LoadInst, StoreInst, and VAArgInst are treated specially. Why aren't AtomicCmpXchgInst and AtomicRMWInst treated with similar care? Lumping together with other unknown instructions seems unnecessarily expensive in compile time. Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120119/6e50526f/attachment....

...ng SuccessOrdering, + AtomicOrdering FailureOrdering, + SynchronizationScope SynchScope = CrossThread) { + return Insert(new AtomicCmpXchgInst(Ptr, Cmp, New, SuccessOrdering, + FailureOrdering, SynchScope)); } AtomicRMWInst *CreateAtomicRMW(AtomicRMWInst::BinOp Op, Value *Ptr, Value *Val, AtomicOrdering Ordering, diff --git a/include/llvm/IR/Instructions.h b/include/llvm/IR/Instructions.h index c249f87..bf39b21 100644 --- a/include/llvm/IR/Instructions.h +++ b/include/llvm/IR/Instruct...

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

...ST(27, Load , LoadInst ) // Memory manipulation instrs -HANDLE_MEMORY_INST(28, Store , StoreInst ) -HANDLE_MEMORY_INST(29, GetElementPtr, GetElementPtrInst) -HANDLE_MEMORY_INST(30, Fence , FenceInst ) -HANDLE_MEMORY_INST(31, AtomicCmpXchg , AtomicCmpXchgInst ) -HANDLE_MEMORY_INST(32, AtomicRMW , AtomicRMWInst ) - LAST_MEMORY_INST(32) + FIRST_MEMORY_INST(27) +HANDLE_MEMORY_INST(27, Alloca, AllocaInst) // Stack management +HANDLE_MEMORY_INST(28, Load , LoadInst ) // Memory manipulation instrs +HANDLE_MEMORY_INST(29, Store , StoreInst ) +HANDLE_MEMORY_INST(30, GetElementPtr, GetElementPtrInst) +HANDLE...

...l control-flow? Something else? 2) Number of new pseudo-instructions which must be introduced * You'd need new pseudos for each word-sized atomicrmw which expands to an ll/sc loop, and an additional one for the masked form of the operation. You could reduce the number of pseudos by taking the AtomicRMWInst::BinOp as a parameter. The code to map the atomic op to the appropriate instruction is tedious but straight-forward. > Added to that is the fact that actual CPU implementations are often a > lot less restrictive about what can go into a loop than is required > (for example even spilling i...

On 11/19/2014 4:05 AM, Chandler Carruth wrote: > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > 1. Update the synchronization scope field in atomic instructions > from a > single bit to a wider field, say 32-bit unsigned integer. > > > I

...tDataVector*, a vector constant. llvm-py should contain them. c. Instruction class. Four new sub classes of Instruction are added: *FenceInst*, an instruction for ordering other memory operations; *AtomicCmpXchgInst*, an instruction that atomically checks and exchanges values in a memory location; *AtomicRMWInst*, an instruction that atomically reads a memory location, combines it with another value and store the result back. *LandingPadInst *, an instruction that hold the necessary information to generate correct exception handling. llvm-py should support them. d. Passes. Some passes are removed, for...

# RFC: Atomic LL/SC loops in LLVM revisited ## Summary This proposal gives a brief overview of the challenges of lowering to LL/SC loops and details the approach I am taking for RISC-V. Beyond getting feedback on that work, my intention is to find consensus on moving other backends towards a similar approach and sharing common code where feasible. Scroll down to 'Questions' for a summary