similar to: [LLVMdev] What does this error mean: psuedo instructions should be removed before code emission?

On Aug 26, 2010, at 10:50 AM, Yuri wrote: > Also there is a typo: it probably should read pseudo. A pseudo instruction is used internally without llvm, but it does not correspond directly to a real instruction in the target architecture. Before emitting the final compiled code, all the pseudo instructions must be expanded to real instructions. If you're seeing that error, it means that

On 08/26/2010 11:11, Bob Wilson wrote: > A pseudo instruction is used internally without llvm, but it does not correspond directly to a real instruction in the target architecture. Before emitting the final compiled code, all the pseudo instructions must be expanded to real instructions. If you're seeing that error, it means that something was not expanded. > So what is likely to

On 08/26/2010 11:53, Eric Christopher wrote: > It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? > I don't know what is ToT. 42 meanings listed here http://acronyms.thefreedictionary.com/TOT don't seem to apply. Yuri

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo

On Aug 26, 2010, at 12:41 PM, Yuri wrote: > On 08/26/2010 11:53, Eric Christopher wrote: >> It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? >> > > I don't know what is ToT. 42 meanings listed here http://acronyms.thefreedictionary.com/TOT don't seem to apply.\ ToT = "top of

On Aug 26, 2010, at 11:47 AM, Yuri wrote: > On 08/26/2010 11:11, Bob Wilson wrote: >> A pseudo instruction is used internally without llvm, but it does not correspond directly to a real instruction in the target architecture. Before emitting the final compiled code, all the pseudo instructions must be expanded to real instructions. If you're seeing that error, it means that

On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > On 08/26/2010 13:17, Dale Johannesen wrote: >>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug

On 08/26/2010 13:17, Dale Johannesen wrote: >>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be getting

On 08/26/2010 11:53, Eric Christopher wrote: > Could you get it to print out the instruction when it happens? (just change the line above the error message to print it out to errs()). > > It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? > Insn before the error: TCRETURNri64 %RAX<kill>, 0,

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false) at

On Aug 27, 2010, at 10:49 AM, Dale Johannesen wrote: > > On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > >> On 08/26/2010 13:17, Dale Johannesen wrote: >>>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>>> >>>> Odd. I thought

On Aug 26, 2010, at 12:25 PM, Yuri wrote: > On 08/26/2010 11:53, Eric Christopher wrote: >> Could you get it to print out the instruction when it happens? (just change the line above the error message to print it out to errs()). >> >> It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? >>

On Aug 27, 2010, at 3:43 PMPDT, Yuri wrote: > On 08/27/2010 12:13, Dale Johannesen wrote: > Here's what happens: > The first instruction created is RET. > SelectBasicBlock is called. > TCRETURNri64 is created from within it. > HasTailCall is set to true as you mentioned. > Cycle in SelectionDAGISel::SelectBasicBlock skips the rest. > > All like you described. But

On Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction:

On 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is

On 08/27/2010 12:13, Dale Johannesen wrote: > I don't think I believe this; emitPrologue should not be generating a > TCRETURN at all, and line 1037 is generating a PROLOG_LABEL. Why do > you say it's a TCRETURN? Sorry, my bad. I have set breakpoints by MI addresses. But it turns out that these addresses were reused and the second MIs created at these particular addressed

----- Original Message ---- > From: Chris Lattner <clattner at apple.com> > To: Yuri <yuri at rawbw.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Sun, February 20, 2011 3:26:35 AM > Subject: Re: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule > > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >>

Hi all (and Andy!), When running a randomForest run in R, I get the last part of an output (with do.trace=T) that looks like this: 1993 | 0.04606 130.43 | 1994 | 0.04605 130.40 | 1995 | 0.04605 130.43 | 1996 | 0.04605 130.43 | 1997 | 0.04606 130.44 | 1998 | 0.04607 130.47 | 1999 | 0.04606 130.46 | 2000 | 0.04605 130.42 | With the first column representing the

This function (understandably) takes quite a long time, because it has to go through each function in module and write its binary. But it probably can be parallelized if different threads would write binaries separately, and then merge them together. Is this implemented or planned? Yuri