search for: usescustomdagschedinserter

...level? If yes, could you > give a > simple example or some hint how it would be done? I only find > examples where > exactly one instruction is emitted (and/or returned). It's not. It requires updating CFG. I'd do this as a separate pass. Another possibility is to use the usesCustomDAGSchedInserter hack. That is, isel to a pseudo instruction and expand it to a series of instructions and update cfg at scheduling time. Look for the usesCustomDAGSchedInserter in X86InstrInfo.td and EmitInstrWithCustomInserter in X86ISelLowering.cpp. Evan > > Do you think it's the right appro...

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, TII->get(is64bit ? PPC::LDARX :...

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) + .addReg(ptrA)...

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

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 : Pseudo< >> >> The "let Uses = [R0]" is not needed. The pseudo instruction will be >> expanded like this later: >> >> + BuildMI(BB, TII-&g...

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

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 each target that uses ldl/stc sequences to have to all implement it....

...sel graph into the sched graph. Unfortunately, this will not work with extra definitions (call clobbered regs in your case). Perhaps the easiest way to handle this whole thing is to add an integer operand to the DAG call node that indicates the calling convention used. You can then use a 'usesCustomDAGSchedInserter' inserter to create the machine instr any way you like based on this information. See the PPC backend and how it inserts SELECT_CC_I4, for example. In your case, you would result in one machine instr (instead of the many SELECT_CC_I4 produces). > P.S. Chris, have you seen this mail fr...

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

Evan Cheng wrote: > 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(). How does this look? It's a big patch, but it basically does this: - Adds A...

On Fri, 17 Nov 2006, Roman Levenstein wrote: > I still have some questions about FP emulation for my embedded target. > To recap a bit: > My target only has integer registers and no hardware support for FP. FP > is supported only via emulation. Only f64 is supported. All FP > operations should be implemented to use i32 registers. ok > allocation. But anyway, I have an almost

I was working on compare and swap and ran into the following problem. Several architectures implement this with a load locked, store conditional sequence. This is good, for those archs I can write generic code to legalize a compare and swap (and most other atomic ops) to load locked store conditional sequences (then the arch only had to give the instr for ldl, stc to support all atomic ops (this

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(). Evan On Jun 30, 2008, at 6:10 AM, Gary Benson wrote: > Chris Lattner wrote: >> On Jun...

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

Hi, I still have some questions about FP emulation for my embedded target. To recap a bit: My target only has integer registers and no hardware support for FP. FP is supported only via emulation. Only f64 is supported. All FP operations should be implemented to use i32 registers. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to

Hi, My target supports shift with amount 1 only i.e. to shift a value by 5 bits, I need to have a loop with shift in the body. Similarly for the unknown amount of shift we need to have a loop for shift. 1) How can I insert this loop in DAG for shift operation? 2) Is there a way where I can have a call to a function and later expand to the shift code? Which would be the

Any idea how to handle "adde" nodes for processors that do not have an "add with carry" instruction? In our case, we rely on "carry test" and "increment" instrunctions. Any reference to a similiar existing LLVM target will be helpful.. TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

...on, but before any other passes including regiser allocation? I have not found any easy way to do it yet. For post-RA pass it is very easy and supported, but for pre-RA or post-code-selection - it is non obvious. I was thinking about to possibilities: 1) Mark all f64 load/store/move target insns as usesCustomDAGSchedInserter = 1 and then intercept in the InsertAtEndOfBasicBlock() their expansion. This should be fine, since at this stage machine insns are still using the virtual registers and it happens before register allocation. Then this function could expand them into pairs of insns operating on i32 virtual regs. Th...

...reateVirtualRegister. 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 : Pseudo< > >> > >> The "let Uses = [R0]" is not needed. The pseudo instruction will be > >> expanded like this later: > >&g...

...F texternalsym:$dst)>; -// Atomic operations. -def LDARX : Pseudo<(outs G8RC:$rD), (ins memrr:$ptr, i32imm:$label), - "\nLa${label}_entry:\n\tldarx $rD, $ptr", - [(set G8RC:$rD, (PPClarx xoaddr:$ptr, imm:$label))]>; +// Atomic operations +let usesCustomDAGSchedInserter = 1 in { + let Uses = [CR0] in { + def ATOMIC_LOAD_ADD_I64 : Pseudo< + (outs G8RC:$dst), (ins memrr:$ptr, G8RC:$incr), + "${:comment} ATOMIC_LOAD_ADD_I64 PSEUDO!", + [(set G8RC:$dst, (PPCatomic_load_add xoaddr:$ptr, G8RC:$incr))]>; + def ATOMIC_CMP_SWAP_I64 : P...