similar to: [LLVMdev] Possible bug in LiveIntervals (triggered on the XCore target)?

Roman Levenstein wrote: > Hi again, > > Now, after I fixed the graph coloring regalloc bug that was triggered > by the ARM target, I continue testing and found another bug, this time > on the XCore target. First I thought that it is again specific to my > register allocator, but it seems to be trigerred also by LLVM's > linearscan register allocator. > > I don't

On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote: > Roman Levenstein wrote: >> Hi again, >> >> Now, after I fixed the graph coloring regalloc bug that was triggered >> by the ARM target, I continue testing and found another bug, this >> time >> on the XCore target. First I thought that it is again specific to my >>

Evan Cheng wrote: > On Jan 13, 2009, at 11:20 AM, Richard Osborne <richard at xmos.com> wrote: > > >> Roman Levenstein wrote: >> >>> Hi again, >>> >>> Now, after I fixed the graph coloring regalloc bug that was triggered >>> by the ARM target, I continue testing and found another bug, this >>> time >>> on

On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote: >> Evan > OK, that make sense, I'll take a look at changing this. I've added a > bug > for the issue: > > http://llvm.org/bugs/show_bug.cgi?id=3324 > > There is currently no Backend: XCore component in bugzilla so I've put > it under new-bugs. Could someone add this component for me. Added. You

Hi Richard, Thanks for working on this! Your patched solved my initial problem, but introduced another one. Please find attached another BC file that fails on xcore with the linear scan regalloc. This is the error message I get eliminateFrameIndex Frame size too big: -3 0 llc 0x08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972

Chris Lattner wrote: > On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote: > > >>> Evan >>> >> OK, that make sense, I'll take a look at changing this. I've added a >> bug >> for the issue: >> >> http://llvm.org/bugs/show_bug.cgi?id=3324 >> >> There is currently no Backend: XCore component in bugzilla so

Roman Levenstein wrote: > Hi Richard, > > Thanks for working on this! Your patched solved my initial problem, > but introduced another one. Please find attached another BC file that > fails on xcore with the linear scan regalloc. > > This is the error message I get > eliminateFrameIndex Frame size too big: -3 > 0 llc 0x08affd1e > 1 libc.so.6 0xb7d35a01 abort

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

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:

Chris Lattner wrote: > > Thanks, this works! I don't yet understand why spill code is needed there > > at all, but I'll return to that when I have branches working correctly. > > I'm not sure either. Can you send the code before and after register > allocation? Attached. > You might also try -regalloc=linearscan, as the default > allocator is, uhhh,

2009/1/13 Evan Cheng <echeng at apple.com>: > > 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]

2009/6/12 Bob Wilson <bob.wilson at apple.com> > Thanks, this should be useful. What problem did you have with svn > revisions after 70786? /tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/xgcc -B/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/ -B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/bin/

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> 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,

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

Hello all. At XMOS we are working towards updating the upstream XCore backend for newer versions of the chip. XCore is the XMOS processor. The XCore backend was written by Richard Osborne at XMOS. Richard has moved on. The current code owner in CODE_OWNERS.TXT, Robert Lytton, has also moved on. For some years XMOS has developed the compiler in-house, for new versions of the chip, but not

Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a subdirectory like the rest of the other targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). Anton is planning to move MSP430 to use the same approach. Having all the targets use the same design simplifies the build system and keeps the target architecture more

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

> Chris Lattner wrote: > >> Hi XCore and PIC16 maintainers, >> >> I'd appreciate it if you guys could move your AsmPrinter >> implementation to be in a subdirectory like the rest of the other >> targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). >> I've moved the XCore AsmPrinter in r79094:

Chris Lattner wrote: > Hi XCore and PIC16 maintainers, > > I'd appreciate it if you guys could move your AsmPrinter > implementation to be in a subdirectory like the rest of the other > targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). > Hi Chris, I'll try to get this done either this weekend or early next week. -- Richard Osborne | XMOS

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce