similar to: [LLVMdev] XCore handling unsupported alignment : StackRealignable= false

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

... and so (I infer from that) it should not be patched let alone need any changes. Assuming my inference is correct, any patching should only affect the XCore target and only if there is a good reason why the XCore requires the change. So, is #ifdef around all/most changes the correct way to submit a patch? Robert ________________________________ From: Eric Christopher [echristo at gmail.com]

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,

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

thank you. I'll submit the patch without #ifdef in this case. Robert ________________________________ From: dblaikie at gmail.com [dblaikie at gmail.com] Sent: 14 January 2014 17:03 To: Robert Lytton; echristo at gmail.com; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] test suite 'owner' On Mon Jan 13 2014 at 12:25:14 PM, Robert Lytton <robert at xmos.com<mailto:robert at

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

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

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 know if the XCore target is stable enough in LLVM, or may be I

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

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

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

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 too); (This work is still under review as best way to do it) 'fixing' symbol and type problems e.g name clashes & scope;

I'd like to be Code owner for the XCore backend if no one objects Thanks, Richard -- Richard Osborne | XMOS http://www.xmos.com

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

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

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80:

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?