similar to: [LLVMdev] test suite 'owner'

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,

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

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

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

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' as a physical register. Thus the call

Hi I would like to disable vectorization on the XCore target by default. I assume I need to push_back -fno-vectorize in clang/lib/driver/Tools.cpp for Triple::xcore. Should I also disable the pass in llvm explicitly? I tried setting getNumberOfRegisters in XCoreTTI::TargetTransformInfo viz: unsigned getNumberOfRegisters(bool Vector) const { if (Vector) { return 0; } return

Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- |

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Here is a bit more data. After PrescheduleNodesWithMultipleUses has been run, the following Predecessor/Successor links are 'dumpAll'ed. (I attach the full dumpAll before & after "Prescheduling SU #7 next to PredSU #4 to guide scheduling in the presence of multiple uses") SU(3) Predecessors: val SU(5): Latency=1 ch SU(7): Latency=1 val SU(7): Latency=1 SU(7):

On Sep 10, 2013, at 8:59 AM, Robert Lytton <robert at xmos.com> wrote: > 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

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

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

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