search for: xmos

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

We have an opening for three compiler engineers at XMOS (Location: Bristol, United Kingdom). Details below. If you are interested please apply by going to http://www.xmos.com/company/jobs. --- Three compiler engineers required to expand the Tools Team. As part of a small but expanding team, these roles will provide strong career development opport...

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

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

...to: 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 or getelementptr I'm missing that mean it's OK to change this from an unsigned comparison to a signed comparison? -- Richard Osborne | XMOS http://www.xmos.com

...lLLVMipo -lLLVMVectorize -lLLVMBitWriter ... -lz -ltinfo -lrt -ldl -lm Is there any reason for this? It just seems to make it harder to parse the output of llvm-config, but I wanted to check that it wasn't intentional before putting together a patch. Thanks, Richard -- Richard Osborne | XMOS http://www.xmos.com

...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 Osborne | XMOS http://www.xmos.com

...t: [LLVMdev] test suite 'owner' Some of these are pretty weird, e.g. int32_t main. Probably the best thing is to submit each patch individually with an explanation of what the purpose is and we can talk about them then. -eric On Fri Jan 10 2014 at 4:13:47 AM, Robert Lytton <robert at xmos.com<mailto:robert at xmos.com>> wrote: Hi, I have found it necessary to make some changes to the test-suite for the XCore platform. These changes include: altering #includes, as supported by XCore; using stdout or stderr to make the output diffs consistent (fixing expected output...

...emitted inline. This fixes the problem on the XCore target. > > I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed. > > -- > Richard Osborne | XMOS > http://www.xmos.com > > <jt.patch>

...is fixes the problem on the XCore target. >> >> I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed. >> >> -- >> Richard Osborne | XMOS >> http://www.xmos.com >> >> <jt.patch> >> > -- Richard Osborne | XMOS http://www.xmos.com

...08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972 llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>, int, llvm::RegScavenger*) const + 1570 Aborted Could you check what is still wrong? -Roman 2009/1/14, Richard Osborne <richard at xmos.com>: > 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 is...

...was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all types). Alternatively would it make sense to make it configurable in the datalayout string? -- Richard Osborne | XMOS http://www.xmos.com

...4 To: Robert Lytton; llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] test suite 'owner' The idea is that it's going to be a correct and portable set of code that works both as a correctness and performance test suite. -eric On Mon Jan 13 2014 at 12:22:51 PM, Robert Lytton <robert at xmos.com<mailto:robert at xmos.com>> wrote: 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...

...e. >> > > Added. You should also be automatically CC'd on anything filed to > that component, > > -Chris > Thanks, I've just commited a fix in r62238: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072150.html -- Richard Osborne | XMOS http://www.xmos.com

...te it by just modifying > > our backend? > > Thank you in advance. > > Minwook Ahn Have you told LLVM the result of setcc operations is 0 or 1? Add the following to the constructor of your ISelLowering class: setBooleanContents(ZeroOrOneBooleanContent); -- Richard Osborne | XMOS http://www.xmos.com

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

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 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 in Target...

...f that's the intended use of this flag. I notice that divide / remainder instructions for other architectures are not marked in this way. Also it is also pessimistic: if the divisor is know to be non zero then the instruction couldn't trap and would be safe to motion. Richard Osborne | XMOS http://www.xmos.com

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