similar to: [LLVMdev] compare and swap

The current *hack* solution is to mark your pseudo instruction with usesCustomDAGSchedInserter = 1. That allows the targets to expand it at scheduling time by providing a EmitInstrWithCustomInserter() hook. You can create new basic blocks then. Evan On Feb 19, 2008, at 4:51 PM, Andrew Lenharth wrote: > I was working on compare and swap and ran into the following problem. > Several

On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: > Anyone have an idea? The patch as it stands is attached below. X86 > is a pseudo instruction because the necessary ones and prefixes aren't > in the code gen yet, but I would imagine they will be (so ignore that > ugliness). The true ugliness can be seen in the alpha impl which open > codes it, including a couple

Torvald Riegel wrote: > On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: >> Anyone have an idea? The patch as it stands is attached below. X86 >> is a pseudo instruction because the necessary ones and prefixes aren't >> in the code gen yet, but I would imagine they will be (so ignore that >> ugliness). The true ugliness can be seen in the alpha impl

On 2/19/08, Evan Cheng <evan.cheng at apple.com> wrote: > The current *hack* solution is to mark your pseudo instruction with > usesCustomDAGSchedInserter = 1. That allows the targets to expand it > at scheduling time by providing a EmitInstrWithCustomInserter() hook. > You can create new basic blocks then. I guess that can work in the short term. It just seems wasteful for

On 2/21/08, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > why is the intrinsic name not CAS? And having another version that returns > just a bool might be better in some cases ( 1. does CAS return the value on > all architectures? 2. you can just jump based on a flag and don't need to > compare it again). Just my 2 cents though ... I was going from

On Thu, Feb 21, 2008 at 9:34 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On 2/21/08, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > > why is the intrinsic name not CAS? And having another version that returns > > just a bool might be better in some cases ( 1. does CAS return the value on > > all architectures? 2. you can just jump based

Hi Evan, Evan Cheng wrote: > The patch looks great. But I do have one comment: > > +let usesCustomDAGSchedInserter = 1 in { > + let Uses = [CR0] in { > + let Uses = [R0] in > + def ATOMIC_LOAD_ADD_I32 : Pseudo< > > The "let Uses = [R0]" is not needed. The pseudo instruction will be > expanded like this later: > > + BuildMI(BB,

Look for createVirtualRegister. These are examples in PPCISelLowering.cpp. Evan On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> The patch looks great. But I do have one comment: >> >> +let usesCustomDAGSchedInserter = 1 in { >> + let Uses = [CR0] in { >> + let Uses = [R0] in >> + def ATOMIC_LOAD_ADD_I32 :

On 2/21/08, Chandler Carruth <chandlerc at gmail.com> wrote: > My strongest feeling is that "swap" has no place in an SSA IR, and the > idea of atomically loading, comparing, and storing is far more in > keeping. In fact, I thought the "swap" instrinsic had even been re-named > to "ls" for load-store at some point this summer.. Do you have those

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel > <torvald at se.inf.tu-dresden.de> wrote: >> On Tuesday 13 July 2010 19:48:25 you wrote: >>> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >>> > I thought that the layout of structs was supposed to be preserved (wrong

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, The patch looks great. But I do have one comment: +let usesCustomDAGSchedInserter = 1 in { + let Uses = [CR0] in { + let Uses = [R0] in + def ATOMIC_LOAD_ADD_I32 : Pseudo< The "let Uses = [R0]" is not needed. The pseudo instruction will be expanded like this later: + BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest) +

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

On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >>> <torvald at se.inf.tu-dresden.de> wrote:

On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >> <torvald at se.inf.tu-dresden.de> wrote: >>> On Tuesday 13 July 2010 19:48:25 you wrote: >>>> On Tue, Jul 13, 2010 at 10:09

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 case in the atomic_ops model, and also on ia64 I think. > The single instruction constraints can,

Hi, I'm currently trying to modify LLVM to include runtime checks into X86 binaries. I've looked into some of the possibilities during the phases happening in LLVM and have the impression that inserting runtime checks during selection would be great, since lots of optimizations are already done and I can work directly with X86 instructions. I've read through the documentation for