search for: expandpostrapseudo

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 looked more closely at the targets that implemented expandPos...

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

...understand the problem better. > > So my base scheme for all of this was to create multi line assembler expansion in pseudos. > > Now that I'm passing mostly all of test-suite, I'm starting improve things. > > At this time, I'm starting to place expansion in > expandPostRAPseudo > > Would it be possible to call this same code during instruction selection? > > When I emitting the code for certain formats, I would need to call some emitter which basically the same kind of I'm calling from expandPostRAPseudo now. expandISelPseudos is the place to cleanup a...

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

...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() 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 looked mor...

...t;> So my base scheme for all of this was to create multi line assembler >> expansion in pseudos. >> >> Now that I'm passing mostly all of test-suite, I'm starting improve >> things. >> >> At this time, I'm starting to place expansion in >> expandPostRAPseudo >> >> Would it be possible to call this same code during instruction selection? >> >> When I emitting the code for certain formats, I would need to call some emitter which basically the same kind of I'm calling from expandPostRAPseudo now. > > expandISelPseudos is...

...ss and then make things better as I understand the problem better. So my base scheme for all of this was to create multi line assembler expansion in pseudos. Now that I'm passing mostly all of test-suite, I'm starting improve things. At this time, I'm starting to place expansion in expandPostRAPseudo Would it be possible to call this same code during instruction selection? When I emitting the code for certain formats, I would need to call some emitter which basically the same kind of I'm calling from expandPostRAPseudo now. >> On Feb 16, 2013, at 1:08 PM, Reed Kotler <rkotler...

...eal instructions? -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 was planning to use expandPostRAPseudo. >> >> Is there a better place? >> >> TIA. >> >> Reed >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://l...

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.

...assConfig::addPreEmitPass() >> > > There is a target-independent pass that will try to expand all pseudo > instructions after register allocation. For each instruction, it will > 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 targ...

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:

...(i64 (XSTGMVINI i64:$addr)) ) )]>; } GlobalAddresses get lowered to RelAddr nodes in our ISelLowering code. Now I just need to be able to expand this in our overridden expandPostRAPseudo function, however, I'm a bit worried that expansion happens too late (after things should already be MI's, it seems). So things like patterns that try to match on that XSTGMVINI would have already been matched. [as an aside, we've got patterns like: def : Pat<(XSTGMVINI tglobaladd...

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(&q...

...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() !=...

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

...foldMemoryOperand to turn a normal def into an early-clobber and vice versa. This is not easy to fix, could you file a PR, please? As a workaround, you can use a pseudo-instruction in loadRegFromStackSlot() that doesn't have the early-clobber flag. Then replace it with the real instruction in expandPostRAPseudo(). /jakob

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 > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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