similar to: [LLVMdev] Compiler job opportunities at XMOS

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 posted to the list a few weeks ago about the possibility of getting a backend XMOS has developed for a new processor accepted back upstream, see http://thread.gmane.org/gmane.comp.compilers.llvm.devel/16005. I've finally got around to updating the backend to build against the svn trunk and got approval to contribute the code. Shall I just just submit the patch to the llvm-commits list?

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

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

LLVM Developers, The compiler teams at the Qualcomm Innovation Center are hiring. In summary, we are doing interesting things with LLVM; come join us! I have included a more detailed description below. If you are interested, please contact me at adasgupt at quicinc.com -Anshu --- Opportunities at Qualcomm Innovation Center, Inc. Compiler Technologies Mobile devices are increasingly supporting

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, SARC System Performance Architecture is seeking a full time compiler engineer to join a world class compiler team supporting Samsung ARM microprocessor designs. Responsibilities include research, design, development, analysis, and optimization of open-source LLVM compiler and Android open-source runtime libraries. The compiler engineer will assist in establishing Samsung’s direction and

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

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

Open Source Job Opportunities Cisco is hiring Open Source engineering professionals in San Jose, California, Research Triangle Park, North Carolina and Richardson, Texas. Join the group that will change the way Cisco develops software. Be part of the Cisco organization that is driving the evolution and expansion into new technology areas and market segments. This group is responsible for

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

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

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

Hi All, Am looking for Ruby on Rails Developers and Testers for Full time Job Opportunities. Below are the available job opportunities:- 1. Position: Lead/Senior Application Engineer Location: San Mateo, CA Duration: Fulltime/ Contract to Hire Requirements: Developed usable, responsive applications in Ruby on Rails or Java / Spring / Hibernate Experience with UI frameworks (such as RoR and a

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

On 07/05/12 22:58, Dan Gohman wrote: > What kind of things might basic block metadata be used for? > > Dan I'd be really keen for this to go in. In order to support worse case execution time analysis on compiled binaries we (XMOS) need a way to mark paths that should be excluded when checking timing constraints. A typical query is "Check the worse case execution time from A to

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

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