search for: r2imap_

I've tried to implement the isMoveInstr method from TargetInstrInfo class, and the register allocator immediately started to crash, in: #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) at ../lib/CodeGen/LiveIntervals.cpp:493 493 assert(r2iA != r2iMap_.end()); The instruction it crashes is: (gdb) p $4.dump() %reg1056 = move %gr7 And gr7 is exactly the register which is looked up with Reg2IntervalMap::iterator r2iA = r2iMap_.find(regA) on line 492. I'm not sure the about the logic, but seems the code tries to map register into live...

...ter register > allocation? Attached. > You might also try -regalloc=linearscan, as the default > allocator is, uhhh, non-optimal. Ehm.... I get this: llc: LiveIntervals.cpp:166: virtual bool llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&): Assertion `r2iit != r2iMap_.end()' failed. - Volodya -------------- next part -------------- Code after instruction selection # Machine code for _Z3addii(): <fi #-2> is 4 bytes fixed at location [SP-20] <fi #-1> is 4 bytes fixed at location [SP-16] entry (0x8681458): %reg1024 = load <fi#-1> %reg1...

...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() && "Interval does not exist for register"' failed. I attach the BC file generated by bugpoint, so that you can reproduce it. The command-line I use is: llc --regalloc=linearscan --march=xcore -f bugpoint-reduced-simplified.bc Any ideas about the reasons of this bug?...

...e used. > > You might also try -regalloc=linearscan, as the default > > allocator is, uhhh, non-optimal. > > Ehm.... I get this: > > llc: LiveIntervals.cpp:166: virtual bool > llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&): Assertion > `r2iit != r2iMap_.end()' failed. Hrm, that's obviously really bad. Can you send me (offline) the output of llc with the -debug option set and with this code before the assert: std::cerr << "MI: " << i << " " << reg << " "; mii->dump(); Also...

...plement the isMoveInstr method from TargetInstrInfo class, and > the register allocator immediately started to crash, in: > > #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) > at ../lib/CodeGen/LiveIntervals.cpp:493 > 493 assert(r2iA != r2iMap_.end()); > > The instruction it crashes is: > > (gdb) p $4.dump() > %reg1056 = move %gr7 > > And gr7 is exactly the register which is looked up with > > Reg2IntervalMap::iterator r2iA = r2iMap_.find(regA) > > on line 492. I'm not sure the about the logi...

...blocks they are used. Oh, I now understand why you say default allocator is not very efficient. > > Ehm.... I get this: > > > > llc: LiveIntervals.cpp:166: virtual bool > > llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&): > > Assertion `r2iit != r2iMap_.end()' failed. > > Hrm, that's obviously really bad. Can you send me (offline) the output of > llc with the -debug option set and with this code before the assert: > > std::cerr << "MI: " << i << " " << reg << " "...

...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() && "Interval does not exist for > register"' failed. > > I attach the BC file generated by bugpoint, so that you can reproduce it. > > The command-line I use is: > llc --regalloc=linearscan --march=xcore -f bugpoint-reduced-simplified.bc > > Any...

...heuristics.Tpo -c /tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c -fPIC -DPIC -o .libs/mf-heuristics.o cc1: /tmp/llvm-project.p28262/src/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:134: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed. /tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c:175: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs/> f...

...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() && "Interval does not exist for >> register"' failed. >> >> I attach the BC file generated by bugpoint, so that you can >> reproduce it. >> >> The command-line I use is: >> llc --regalloc=linearscan --march=xcore -f bugpoint-r...

On Jun 11, 2009, at 7:18 PM, Misha Brukman wrote: > I've committed my scripts that simplify building Linux/x86 -> Linux/ > ARM crosstool. There are 2 parts to using this: > > * llvm/utils/crosstool/create-snapshots.sh > creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific > revision of your choice > * llvm/utils/crosstool/ARM/build-install-linux.sh

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > I assume that the two unconditional gotos are just test code, right? If > > not, the second one is dead. > > Yes, in the final form there will be "iflt" instruction before the first goto, > making it conditional. Ah, ok :) > > > The code after "goto" is disturbing. It looks like spill code, but

...#39;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() && "Interval does not exist for >>> register"' failed. >>> >>> I attach the BC file generated by bugpoint, so that you can >>> reproduce it. >>> >>> The command-line I use is: >>> llc --regalloc=linearscan...

Chris Lattner wrote: > On Tue, 8 Jun 2004, Vladimir Prus wrote: > > While adding support for branch instructions in my backend, I run into a > > trouble. The code to handle branches looks like: > > The machine code after instruction selection is: > > > > entry (0x8681458): > > %reg1024 = load <fi#-1> > > %reg1025 = load