similar to: [LLVMdev] jump to function

The generated code is deterministic, but the global order the instructions were generated seems it is not (although the result is guaranteed to be the same). Now I think the order functions are processed might not be guaranteed. I've attached a test case, and here is what I get: ............................... (303)$ ~/bin/llvm/bin/gcc -O3 -emit-llvm try_calls_basic.2.c -c -o

All; I am getting an error about an app not loading. The error I get is: Module 'app_machinedetect.so' did not register itself during load Can someone shed some light on what I am missing here? Any help at all would be greatly appreciated. Thanks _________________________________________________________________ Insert movie times and more without leaving Hotmail?.

Hello, For debugging purposes, I've added a unique id member to the Value class: global_next_vuid = 0; Value::Value(..){ vuid = ++global_next_vuid; } My hope is that by looking at the vuid of a Value, I can see its vuid, set a conditional breakpoint and re-run the compiler to see who (what pass) constructed that value. Maybe I am not doing it the right way, but the above 'vuid'

On Mon, May 18, 2009 at 8:33 PM, dan mihai <dnmh68 at hotmail.com> wrote: > Hello, > Yo! > For debugging purposes, I've added a unique id member to the Value class: > > global_next_vuid = 0; > Value::Value(..){ >   vuid = ++global_next_vuid; > } > > My hope is that by looking at the vuid of a Value, I can see its vuid, > set a conditional breakpoint and

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

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 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

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

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

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

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

Hi Eric, Could you explain the intent and policy regarding the test-suite body of code. Should the test be left as much as possible as-is (even if technically incorrect)? Should changes only affect the XCore target (#ifdef) or should all targets get the changes? Taking "int32_t main" as an example. The correct return type & argc for main is 'int'. In the XCore tool chain,

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. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

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

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, 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

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

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