similar to: [LLVMdev] Old-style code generators broken?

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just

On Fri, 2 Feb 2007, Nicolas Geoffray wrote: > I have almost completed the implementation of a linux/ppc backend in llvm. Cool! > There were a few things to modify in > lib/Target/PowerPC with a lot of "if (!isDarwin)". Some meta comments: 1. Please don't change PPC -> llvmPPC. I assume that you did this because PPC is a #define in some system header. Please

Hi everyone, I have almost completed the implementation of a linux/ppc backend in llvm. There were a few things to modify in lib/Target/PowerPC with a lot of "if (!isDarwin)". There are some places where I need help before saying the port is complete. I attached the diff file as a reference 1) In order to generate a creqv instruction before a vararg call, I created a new

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

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/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 Sat, 14 Oct 2006, Roman Levenstein wrote: >> On Sat, 14 Oct 2006, Roman Levenstein wrote: >>> Is it possible to dynamically define implicit defs for some >>> instructions? >> >> Yes! This is what explicit operands are :). Specifically, if you >> want to >> vary on a per-opcode basis what registers are used/def'd by the >> instruction,

Hi Micah, the register use list gets dropped by the instruction selector because you didn't specify "variable_ops" in the input operand list of your CALL instruction. It has to look like this: (ins calltarget:$dst, variable_ops) Regards, Christoph

I think the easiest thing for you to do is to define a separate CALL instruction with a different set of Defs. This instruction should only be selected when the predicate isMacho is true. Also update PPCRegisterInfo.cpp getCalleeSavedRegs() to return a different list when subtarget->isMachoABI() is true. Evan On Feb 14, 2007, at 7:19 AM, Nicolas Geoffray wrote: > Hi Chris, >

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

Hello, When I run LLC with option "-O0 -march=sparc" on following testcase, fast register allocator crashes with "UNREACHABLE executed" error. LLC generates code successfully with other standard register allocators available. $ cat call.ll define void @test() nounwind { entry: %0 = tail call i32 (...)* @foo() nounwind tail call void (...)* @bar() nounwind ret void }

Thanks Cristoph, I have that code in my backend, but unless I do the following, the registers are never considered 'live' into the call. / Handle a function call let isCall = 1, Defs = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31, R32, R33, R34, R35, R36, R37, R38, R39, R40, R41,

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

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

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

Andrew Lenharth wrote: > On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: >> - No varargs > > What are your issues here? Or are they simply at the "not implemented > so I don't know" stage? The two bugs I mentioned (no varargs, no alloca) are pretty much two sides of the same coin: I'm ignoring the IA64 stack frame layout (for no good reason), so

On Monday 19 January 2009 18:21, Dan Gohman wrote: > > Dan, how does the scheduler handle memory dependence? I'm working on > > something that requires memory dependence information for > > MachineInstructions. > > At the moment, it knows simple things, like constant pool loads > don't have dependencies, and references to distinct stack slots are >

On Fri, 18 Mar 2005, Duraid Madina wrote: >>> - No instruction scheduling/bundling of any sort >> >> So this one needs to be coordinated. Next week, I might see about >> adding MachineInstruction support to the SelectionDAG so you can load up >> a DAG post-ISel and then spit it back out scheduled. > > That would be much appreciated, particularly if it

Hi, On 06/18/2011 06:26 AM, Benjamin Müller wrote: > i created a Function Pass to retrieve the Control/Data Flow Graph from > a simple program, > now i would like to statically schedule the Instructions. Is this > possible by starting to modify the SelectionDAG Files ? > Or can i even build a "standalone" custom scheduler? > Thank you very much for any tipps. You

On Monday 19 January 2009 16:42, Dan Gohman wrote: > >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far