search for: liverangecalc

...bout updating LiveIntervals. > 1. It works well if I just use from step1 to step3, without step4. > 2. In step4, I firstly use UnreachableBlockElim pass to delete OldMBB. > Then, remove all intervals and recompute all the virtual registers' LiveIntervals. > 3. I debug source code in LiveRangeCalc.cpp and copy partial code shown following. > /// LiveRangeCalc.cpp > ... > #ifndef NDEBUG > if (MBB->pred_empty()) { > MBB->getParent()->verify(); > llvm_unreachable("Use not jointly dominated by defs."); > } > ... > /// LiveRangeCal...

On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all the intervals rerun LiveIntervals::computeVirtRegs after all the CFG transforms are complete? Yes, I should think so. /jakob -------------- next part -------------- An HTML attachment was

...Use RemoveMachineInstrFromMaps() to erase SlotIndexes info of OldMBB. And, delete OldMBB from current CFG. Lastly, remove all registers' interval, create and recompute virtual register interval info. >> However, I get an unreachable error "Use not jointly dominated by defs" in LiveRangeCalc.cpp:188. >> So, comparing with Step3, Step4 generates an unreachable error, Why? >> Valid information of OldMBB is deleted when updating CFG? Is there something wrong with my updating steps? >> Thank you very much again. > > I’m haven’t done anything like this so I can...

...firstly, Use RemoveMachineInstrFromMaps() to erase SlotIndexes info of OldMBB. And, delete OldMBB from current CFG. Lastly, remove all registers' interval, create and recompute virtual register interval info. However, I get an unreachable error "Use not jointly dominated by defs" in LiveRangeCalc.cpp:188. So, comparing with Step3, Step4 generates an unreachable error, Why? Valid information of OldMBB is deleted when updating CFG? Is there something wrong with my updating steps? Thank you very much again. -Haishan -------------- next part -------------- An HTML attachment was scrubbed....

...veMachineInstrFromMaps() to erase SlotIndexes info of OldMBB. And, delete OldMBB from current CFG. Lastly, remove all registers' interval, create and recompute virtual register interval info. >>>> However, I get an unreachable error "Use not jointly dominated by defs" in LiveRangeCalc.cpp:188. >>>> So, comparing with Step3, Step4 generates an unreachable error, Why? >>>> Valid information of OldMBB is deleted when updating CFG? Is there something wrong with my updating steps? >>>> Thank you very much again. >>> >>> I’m h...

> I am not sure extending the scavenger is the right way to go about this. > > There are two different situations where we might need extra registers to > spill something: > > 1. When spilling a weird register class like predicate registers, we > already known during register allocation that we will need a scratch GPR > to assist with the spill. > > 2. When spilling

Hi, I insert a new machine basic block(MBB) before Greedy Register Allocation, after Simple Register Coalescing. But I encounter a fatal error "regalloc = ... not currently supported with -O0". I use command line with opt level O2, not O0. The probable reason of this error is that no LiveInterval information for newly MBB which is used by Register Allocation. And, LiveIntervals depend

Reading the comments in Analysis/DominanceFrontier.h, I see a note that the structure is deprecated and we're not to use it for anything new. Has it been replaced with something equally useful, or shall I redo the calculation for myself, or ...? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: > How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). Any help would be appreciated. I did a bit of the easy stuff in 2-addr, it has a LIS = getAnalysisIfAvailable<LiveIntervals>() member that it sometimes updates. It

s/llvm-commits/llvmdev/ On Dec 9, 2011, at 12:58 PM, Arnold Schwaighofer wrote: > >> As Jakob pointed out to me, the core problem is that the current >> register scavenger implementation will only give you one register; for >> the PowerPC case, and it looks like for your case as well, we might >> really need two registers. In the short term, a reasonable solution

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

...r Release+Asserts build llvm[2]: Compiling LivePhysRegs.cpp for Release+Asserts build llvm[2]: Compiling MCAssembler.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugArangeSet.cpp for Release+Asserts build llvm[2]: Compiling MachOObjectFile.cpp for Release+Asserts build llvm[2]: Compiling LiveRangeCalc.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugAranges.cpp for Release+Asserts build llvm[2]: Compiling MCCodeEmitter.cpp for Release+Asserts build llvm[2]: Compiling MCCodeGenInfo.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugFrame.cpp for Release+Asserts build llvm[2]: Co...