similar to: [LLVMdev] Matching an instruction that writes a specific register in a Pat<>

On 25/07/12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", >

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

On 25 Jul 2012, at 04:49, Paul Shortis wrote: > Hello, > > I'm considering creating an LLVM backend for a 16 bit processor and > modelling it around the (experimental) MSP430 back end. > > When reviewing MSP430InstrInfo.td I see > > def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; > > and can see in MSP430ISelLowering.cpp

Hello, This bug affects all LLVM versions from 2.6 to trunk : http://llvm.org/bugs/show_bug.cgi?id=5081 The workaround I found is to add this : Index: lib/Target/X86/X86Instr64bit.td =================================================================== --- lib/Target/X86/X86Instr64bit.td (revision 105882) +++ lib/Target/X86/X86Instr64bit.td (working copy) @@ -1832,6 +1832,8 @@

On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > Hello, > > This bug affects all LLVM versions from 2.6 to trunk : > http://llvm.org/bugs/show_bug.cgi?id=5081 > > The workaround I found is to add this : > > Index: lib/Target/X86/X86Instr64bit.td > =================================================================== > --- lib/Target/X86/X86Instr64bit.td

Hello, I'm considering creating an LLVM backend for a 16 bit processor and modelling it around the (experimental) MSP430 back end. When reviewing MSP430InstrInfo.td I see def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; and can see in MSP430ISelLowering.cpp that ISD::GlobalAddress: ISD::BlockAddress: ISD::ExternalSymbol all get lowered to

On 06/21/2010 08:21 PM, Eric Christopher wrote: > On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > > >> Hello, >> >> This bug affects all LLVM versions from 2.6 to trunk : >> http://llvm.org/bugs/show_bug.cgi?id=5081 >> >> The workaround I found is to add this : >> >> Index: lib/Target/X86/X86Instr64bit.td >>

On 06/22/2010 11:11 AM, Patrick Marlier wrote: > On 06/21/2010 08:21 PM, Eric Christopher wrote: >> On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: >> >> >>> Hello, >>> >>> This bug affects all LLVM versions from 2.6 to trunk : >>> http://llvm.org/bugs/show_bug.cgi?id=5081 >>> >>> The workaround I found is to

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

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

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

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

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

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

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

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

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