search for: liveintervalsanalysi

...ings I can't figure out. Where is PHI elimination done in the linear scan algorithm? From my reading, allocation happens before PHI nodes are eliminated, so where do PHI nodes get removed? The PNE pass declares that it preserved LiveVariables. I take it then that LiveIntervals are lost? In LiveIntervalsAnalysis.cpp there's a statement in the top block comment that it computes intervals conservatively. I would like to understand what information is lost. What does LiveVariables convey that LiveIntervals cannot? Thanks for your help. -Dave

...seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I should just safely skip it during testing because it is not mature yet. Anyway, I report it here - may be it is of some interest. The crash happens in LiveIntervalsAnalysis, inside the spilling function. From what I observe, I'd say it is related to rematerializable intervals. The assertion says: /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() &&a...

LiveVariables gives you something like liveness analysis: where each variable is alive, that is, across each basic blocks, where it is defined, and where it is killed. LiveIntervals gives you a linear representation of the variables as a set of intervals. Yes, it handle holes in the live ranges. There is a very nice description of these analysis and related data structures here:

...R <fi#0>, %reg0, 0, 14, %reg0 >> %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 >> BX_RET 14, %reg0 > > Ok, ignore my earlier email about BX_RET. The issue is LR should be added to > livein of BB #1. Who should do it? Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables should do it or do you mean that my regalloc should do it? > **** Post Machine Instrs **** > # Machine code for Insert(): > Live Ins: R0 in VR#1025 R1 in VR#1026 > > entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: > Live Ins: %R0 %R1 > %LR<def> = MOVr %...

...replace all virtual registers by assigned physical registers. I see different options for doing it: a) Normally, I'd use the spiller provided by the VirtRegMap class. But currently, it assumes that live register has only one physical register assigned to it. b) It could be possible to change LiveIntervalsAnalysis so that it creates a new LiveInterval for each live range. But this will probably have a negative impact on performance and also reduce coalescing possibilities. c) May be LiveIntervals could be split after register allocation, just before rewriting? How this could be easily done? May be PreAlloc...

..., %ac0<imp-use>, %ac1<imp-use>, %a2_32<imp-use> - operand 6: %a2_32<imp-use> I cannot quite figure what's wrong here - the a2_32<imp-use> operand was added by the VirtualRegRewriter, because the partial def was not marked undef. The reason for this was that the LiveIntervalsAnalysis pass cleaned up after REG_SEQUENCE lowering by making the first occurence - when the interval for the reg was empty and thus created - an <def,undef>, but then it does not do the same for the other subreg, as at that time the interval for the reg is not empty. Can anyone say what went wrong...

...M's > linearscan register allocator. > > I don't know if the XCore target is stable enough in LLVM, or may be I > should just safely skip it during testing because it is not mature > yet. Anyway, I report it here - may be it is of some interest. > > The crash happens in LiveIntervalsAnalysis, inside the spilling > function. From what I observe, I'd say it is related to > rematerializable intervals. > > The assertion says: > /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: > llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): > Ass...

...DDri %SP<kill>, 4, 14, %reg0, %reg0 >>>> BX_RET 14, %reg0 >>> >>> Ok, ignore my earlier email about BX_RET. The issue is LR should be added >>> to >>> livein of BB #1. >> >> Who should do it? >> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables >> should do it or do you mean that my regalloc should do it? > > Register allocator should update mbb Livein info. OK. >> >> >>> **** Post Machine Instrs **** >>> # Machine code for Insert(): >>> Live Ins: R0 in VR#1025 R1 in VR#...

...;> %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 >>> BX_RET 14, %reg0 >> >> Ok, ignore my earlier email about BX_RET. The issue is LR should be >> added to >> livein of BB #1. > > Who should do it? > Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables > should do it or do you mean that my regalloc should do it? Register allocator should update mbb Livein info. > > >> **** Post Machine Instrs **** >> # Machine code for Insert(): >> Live Ins: R0 in VR#1025 R1 in VR#1026 >> >> entry: 0x8fdac9...

...locator. >> >> I don't know if the XCore target is stable enough in LLVM, or may >> be I >> should just safely skip it during testing because it is not mature >> yet. Anyway, I report it here - may be it is of some interest. >> >> The crash happens in LiveIntervalsAnalysis, inside the spilling >> function. From what I observe, I'd say it is related to >> rematerializable intervals. >> >> The assertion says: >> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: >> llvm::LiveInterval& llvm::LiveIntervals::getInterval...

...ical registers. I > see different options for doing it: > > a) Normally, I'd use the spiller provided by the VirtRegMap class. But > currently, it assumes that live register has only one physical > register assigned to it. Right. > > > b) It could be possible to change LiveIntervalsAnalysis so that it > creates a new LiveInterval for each live range. But this will probably > have a negative impact on performance and also reduce coalescing > possibilities. Not to mention it will significantly increase memory usage. > > > c) May be LiveIntervals could be split after...

...ons for doing it: >> >> a) Normally, I'd use the spiller provided by the VirtRegMap class. But >> currently, it assumes that live register has only one physical >> register assigned to it. > > Right. > >> >> >> b) It could be possible to change LiveIntervalsAnalysis so that it >> creates a new LiveInterval for each live range. But this will probably >> have a negative impact on performance and also reduce coalescing >> possibilities. > > Not to mention it will significantly increase memory usage. Yes, true. >> c) May be LiveInt...

On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: > Predecessors according to CFG: 0x8fdac90 (#0) > %R0<def> = MOVi 0, 14, %reg0, %reg0 > *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) > [0x8fc2d68 + 0] > %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 >

...t;> I don't know if the XCore target is stable enough in LLVM, or may >>> be I >>> should just safely skip it during testing because it is not mature >>> yet. Anyway, I report it here - may be it is of some interest. >>> >>> The crash happens in LiveIntervalsAnalysis, inside the spilling >>> function. From what I observe, I'd say it is related to >>> rematerializable intervals. >>> >>> The assertion says: >>> /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: >>> llvm::LiveInterval& llvm::Li...

...re is PHI elimination done in the linear scan algorithm? From my > reading, allocation happens before PHI nodes are eliminated, so where > do PHI nodes get removed? > > The PNE pass declares that it preserved LiveVariables. I take it > then that LiveIntervals are lost? > > In LiveIntervalsAnalysis.cpp there's a statement in the top block > comment that it computes intervals conservatively. I would like > to understand what information is lost. What does LiveVariables > convey that LiveIntervals cannot? > > Thanks for your help. > >...

...16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at SlotIndex 748. Why is this? Should I add anything special to the basic BuildMI calls? The LiveIntervalsAnalysis, then adds ranges to 16506 for the whole block - even prior to 732 which is the first subreg-def. This is a loop body, but 16506 is marked as killed at 748, so I don't see why there is a live range from earlier than 732. The coalescer will then report "Interference", and not coalesce...

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is

...files). That pass I call from Mips backend in this way (MipsTargetMachine.cpp): bool MipsPassConfig::addPreRegAlloc() { addPass(createTestPass()); return false; } The problem becomes, when I am trying compile file ldtoa.ll (in attached files). Compiling process ends with errors from LiveIntervalsAnalysis. Everything is ok without TestPass. I don't understand what's going on. My pass doesn't do anything but call analyse. It is strange that the compiling process fails few passes after my pass. Some suggestions? Greetings, Tom P.S.: I work with LLVM 3.2 release. -------------- ne...