similar to: [LLVMdev] No DWARF line number info with HasDotLocAndDotFile = true

Richard Osborne wrote: > It seems to me that emitting DWARF line number information using .loc > directives is currently broken. CellSPU is currently the only in tree > target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it > to produce any line number information. > I think I understand why this is happening. Since HasDotLocAndDotFile is set the

Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! -Chris On Mar 9, 2010, at 6:06 AM, Richard Osborne wrote: > On 02/03/10 00:11, Jim Grosbach wrote: >> On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: >> >>> On 01/03/10 21:14, Chris Lattner

Thanks for reviewing this. Committed in r98255 and r98256. The bug against the ARM backend is 6581: http://llvm.org/bugs/show_bug.cgi?id=6581 On 10/03/10 21:45, Chris Lattner wrote: > Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! > > -Chris > > On Mar

On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: > On 01/03/10 21:14, Chris Lattner wrote: >> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: >> >>> On 23/02/10 14:58, Richard Osborne wrote: >>> >>>> I've recently changed the XCore target to implement BR_JT as a jump to a >>>> series jumps. The jump table entries are

I've recently changed the XCore target to implement BR_JT as a jump to a series jumps. The jump table entries are expand inline in the function so there is no longer a need to emit jump tables at the end of the function. However the emission of jump tables at the end of a function is done inside the AsmPrinter base class and there seems to be no way of disabling this. This also seems to

On 02/03/10 00:11, Jim Grosbach wrote: > On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: > >> On 01/03/10 21:14, Chris Lattner wrote: >> >>> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: >>> >>>> On 23/02/10 14:58, Richard Osborne wrote: >>>> >>>> >>>>> I've recently

On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: > On 23/02/10 14:58, Richard Osborne wrote: >> I've recently changed the XCore target to implement BR_JT as a jump to a >> series jumps. The jump table entries are expand inline in the function >> so there is no longer a need to emit jump tables at the end of the >> function. However the emission of jump tables at

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

If I give instcombine the following IR: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %c = getelementptr [1 x i8]* %a, i32 0, i32 0 %d = getelementptr [1 x i8]* %b, i32 0, i32 0 %cmp = icmp ult i8* %c, %d ret i1 %cmp } It optimizes it into: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %cmp = icmp slt [1 x i8]* %a, %b ret i1 %cmp } Is this a bug, or are there some semantics of icmp

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

With LLVM built from trunk I understand I should now use llvm-config --system-libs to get the system libraries to link against when linking against llvm (as of r197664). If run this then llvm-config outputs a blank line before the system libraries, for example on Linux I get: $ llvm-config --system-libs -lz -ltinfo -lrt -ldl -lm If I use --system-libs together with --libs the LLVM libraries

I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code in TargetData.cpp: if (GV->hasInitializer() && GVAlignment == 0) { if (Alignment < 16) { // If the global

Dear developers. We try to make our own backend of llvm for our target machine. Assume that we have the following code in our source code. int i = ( a < b ); The code is translated into r0 <- gt r1 r2 r3 <- and r0 0x1 We think that r3 is not necessary. Is there any way to eliminate it by just modifying our backend? Thank you in advance. Minwook Ahn -------------- next part

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

What are the correct target description side effect flags for instructions which may trap (e.g. divide / remainder)? The divide instruction in my backend currently has no flags set. I've enabled the MachineLICM pass and it's causing a miscompilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current

Hi, I'm a compiler engineer at XMOS (http://www.xmos.com) and in the last few months I've been working on porting LLVM to target our XS1-G4 chip. I thought it may be of interest to the list to find out how we are using of LLVM. The XS1-G4 has four processors and 32 hardware threads. It has been designed to be highly responsive to I/O events allowing many tasks normally be done by

On Fri, Jun 28, 2013 at 6:13 AM, Richard Osborne <richard at xmos.com> wrote: > If I give instcombine the following IR: > > define i1 @f([1 x i8]* %a, [1 x i8]* %b) { > %c = getelementptr [1 x i8]* %a, i32 0, i32 0 > %d = getelementptr [1 x i8]* %b, i32 0, i32 0 > %cmp = icmp ult i8* %c, %d > ret i1 %cmp > } > > It optimizes it into: > > define i1

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

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

On 20 Jan 2010, at 07:55, minwook Ahn wrote: > Dear developers. > > We try to make our own backend of llvm for our target machine. > > Assume that we have the following code in our source code. > > int i = ( a < b ); > > The code is translated into > > r0 <- gt r1 r2 > r3 <- and r0 0x1 > > We think that r3 is not necessary. Is there any way