search for: tcreturnri64

...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, %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 lowered in emitEpilog...

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

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 with the .ll file that causes this? >> &g...

...>> - insn: %RBP<def> = MOV64rr %RSP >>> - insn: PROLOG_LABEL <MCSym=.Ltmp3> >>> - insn: %RDI<def> = MOV64ri64i32 60910096 >>> - insn: %RAX<def> = MOV64ri >>> <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> >>> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp- >>> def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> - insn: RET >>> * PEI::insertPrologEpilogCode: === << before emitEpilogue >>> >>> Function only has on BB. Is this wrong t...

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 TCReturn was being lowered. At any rate can you file a bug with the .ll file that causes this? >>> >>> It should...

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 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 generated. Normally that's >>> Lowe...

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, DL={LineCol = 0, ScopeIdx = 0}, &g...

...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, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... Yuri

...IT::runFunction (this=0x327a7e0, F=0x4530bd0, ArgValues=@0x7fffffff9230) at /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:405 #16 0x0000000802f4fe4f in llvm::JIT::runFunction (this=0x327a7e0, F=0x4530c60, ArgValues=@0x7fffffff9350) at /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:561 TCRETURNri64 creation stack (created second): #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr (this=0x30eb000, TID=@0x803a9f840, DL={LineCol = 0, ScopeIdx = 0}, NoImp=false) at /tmp/llvm-svn/llvm/lib/CodeGen/MachineFunction.cpp:153 #2 0x00000008028ea302 in llvm::BuildMI (MF=@0x30eb000, DL...

...T on the ml, so I have no idea what might be going > wrong there. I haven't tested it, but the following pattern in X86Instr64bit.td looks suspicious as it appears to attempt to support direct tailcalls to arbitrary 64-bit immediates: def : Pat<(X86tcret GR64:$dst, imm:$off), (TCRETURNri64 GR64:$dst, imm:$off)>; Dan

...e 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, %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? -eric

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 the RET instruction still stays in the > end. > RET is skipped by visit but I guess stays in the list. Where sh...

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so

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