search for: expandpostrapseudos

Thanks for the suggestion, Duncan. I recently figured out that it had to do with how I was removing the pseudo instruction in my overridden expandPostRAPseudo() implementation. // member function's signature bool TheInstrInfo::expandPostRAPseudo(MachineBasicBlock::iterator p_mi) // works bb.erase(p_mi); // produces the assertion / memory leak. p_mi->removeFromParent(); I should have

...Irr %RAX<kill> - operand 1: %RAX<kill> LLVM ERROR: Found 1 machine code errors. This happens because, on entry to the pass, we have %RAX<def> = SUBREG_TO_REG 0, %R9D, 4 %XMM0<def> = MOV64toPQIrr %RAX<kill> The pass converts (around about line 132 in ExpandPostRAPseudos.cpp) the SUBREG_TO_REG pseudo op to %EAX<def> = MOV32rr %R9D Because of "-mcpu-atom", post RA scheduling is enabled, so is post RA liveness tracking. Because the destination has been changed to EAX from RAX in transforming the SUBREG_TO_REG pseudo op into a MOV32rr...

...ed to call some emitter which basically the same kind of I'm calling from expandPostRAPseudo now. expandISelPseudos is the place to cleanup after ISEL hacks, and can create BBs. But, as Cameron explained well in the other thread, if you want a macro assembler for some sequences, do it late in expandPostRAPseudos. -Andy >>> On Feb 16, 2013, at 1:08 PM, Reed Kotler <rkotler at mips.com> wrote: >>> >>>> I have a bunch of pseudos that I want to lower right after instruction selection. >>>> >>>> Where is the best place to do that? >>>>...

I'm using a Hexagon's packetizer as an example to packetize instructions for my custom VLIW. The problem that I'm facing is that my target as it turns out doesn't have all the instructions expanded by the time packetization happens (for example I have a RET instruction which gets expanded into a write to a register and a jump/branch). I'm wondering if Hexagon is experiencing

removeFromParent just unlinks it from the basic block and returns the removed instruction. It does not delete it. On Sun, Jan 20, 2013 at 9:54 PM, David Waggoner <mathonnapkins at gmail.com>wrote: > > Thanks for the suggestion, Duncan. > > I recently figured out that it had to do with how I was removing the > pseudo instruction in my overridden expandPostRAPseudo()

...ch basically the same kind of I'm calling from expandPostRAPseudo now. > > expandISelPseudos is the place to cleanup after ISEL hacks, and can > create BBs. But, as Cameron explained well in the other thread, if you > want a macro assembler for some sequences, do it late in > expandPostRAPseudos. > -Andy > I feel like I should expand things as soon as I have all the information because then other passes can help make things better. So maybe I do this earlier in expandIselPseudos. Are there any cons ? > >>>> On Feb 16, 2013, at 1:08 PM, Reed Kotler<rkotler at mip...

On 02/17/2013 12:48 PM, Andrew Trick wrote: > On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> That's exactly the right place. > Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's as if they're real instructions? You don't want to schedule or register allocate the real

On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: > That's exactly the right place. Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's as if they're real instructions? You don't want to schedule or register allocate the real instructions? -Andy > On Feb 16, 2013, at 1:08 PM, Reed

Hi David, > Previously, I had been testing with only one routine per test .ll file, but I > thought I'd reached a point where I could test multiple operations at once and > understand the output. The odd part about this is that the likelihood of seeing > the above assertion scales with the number of functions in the .ll file. If I > have one or two functions, I never see it.

...check if the instructions is a pseudo-instruction, and if so, it will call > the target hook "expandPostRAPseudo" on that instruction. > > Your target will need to implement TargetInstrInfo::expandPostRAPseudo, > and mark RET as a pseudo-instruction. > > See lib/CodeGen/ExpandPostRAPseudos.cpp for the expanding pass, and the > "expandPostRAPseudo" functions for individual targets to get an idea of how > they work. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _________...

I have a bunch of pseudos that I want to lower right after instruction selection. Where is the best place to do that? I was planning to use expandPostRAPseudo. Is there a better place? TIA. Reed

Hello, I've made some fair progress on a target for 6502 family CPUs recently, but I've run into an error I'm not sure how to address. I've ruminated over it for about a week now, trying various things and not having any success. It seems to scale with the number of routines in my .ll file, which I am trying to run through llc. I get the following stack dump from an assertion:

I've got this PseudoOp defined: def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; let Constraints = "$dst = $addr" in { //, Uses= [GRP] in { def RelAddr : XSTGPseudo< (outs GPRC:$dst), (ins i64imm:$spoff,

Amara, first, thank you for answering. but I found expandPsuedo instructions actually happens before post-RA, like the following code showing: your approach is a little hacky, right? : ) // Expand pseudo instructions before second scheduling pass. addPass(&ExpandPostRAPseudosID); printAndVerify("After ExpandPostRAPseudos"); // Run pre-sched2 passes. if (addPreSched2()) printAndVerify("After PreSched2 passes"); // Second pass scheduler. if (getOptLevel() != CodeGenOpt::None) { addPass(&PostRASchedulerID); printAndVerify(&qu...

...thank you for answering. but I found expandPsuedo instructions > > actually happens before post-RA, like the following code showing: > > your approach is a little hacky, right? : ) > > > > // Expand pseudo instructions before second scheduling pass. > > addPass(&ExpandPostRAPseudosID); > > printAndVerify("After ExpandPostRAPseudos"); > > > > // Run pre-sched2 passes. > > if (addPreSched2()) > > printAndVerify("After PreSched2 passes"); > > > > // Second pass scheduler. > > if (getOptLevel() != C...

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

...s wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the register allocator into doing the right thing, and COPY instructions created by live range splitting. 3. *MCInstLower.cpp - For instructions that need to trick all of codegen. Pseudos should be expanded as early as possible. Many of the instructions curre...

On Jul 15, 2012, at 4:50 PM, Borja Ferrer <borja.ferav at gmail.com> wrote: > I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. > As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code

That's exactly the right place. Cameron On Feb 16, 2013, at 1:08 PM, Reed Kotler <rkotler at mips.com> wrote: > I have a bunch of pseudos that I want to lower right after instruction selection. > > Where is the best place to do that? > > I was planning to use expandPostRAPseudo. > > Is there a better place? > > TIA. > > Reed > > > >

Hi all, I am working on an out-of-tree target. I am wondering if it is possible to force the register allocator (and/or spiller) to not break certain instruction sequence. For example: phys_reg = MI1 vreg1 vreg 2 = MI2 phys_reg Is there a way to tell RA/spiller not to insert COPY or spill between MI1 and MI2? I am using greedy register allocator and inline spiller. -- Regards, Dongrui