search for: fp_reg_kill

.../home/llvm/obj/../lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 79. .text .align 16 .globl test1 .type test1, @function test1: fldl 4(%esp) ftst fstp %st(0) fnstsw sahf setne %al movzbl %al, %eax #FP_REG_KILL ret Abort trap (core dumped) FAIL: /usr/home/llvm/obj/../test/Regression/CodeGen/X86/fast-cc-pass-in-regs.ll: Does not have a RUN line Running /usr/home/llvm/obj/../test/Regression/Debugger/dg.exp ... FAIL: /usr/home/llvm/obj/../test/Regression/Debugger/funccall.ll:

...ops Scalar Evolution Analysis Loop Pass Manager Loop Strength Reduction Lower Garbage Collection Instructions Remove unreachable blocks from the CFG Optimize for code generation Insert stack protectors X86 DAG->DAG Instruction Selection X86 FP_REG_KILL inserter X86 Maximal Stack Alignment Calculator <MY PASS RUNS HERE> > Also, does bb.getBasicBlock() for sure always returns a valid block > refrerence? Yes. I am printing bb and *bb.getBasicBlock() in order to compare the contents of the IR in the BasicBlock and the targe...

...1 in def TAILJMPr : I<0xFF, MRM4r, (ops GR32:$dst), "jmp {*}$dst # TAIL CALL jmpr", []>; On 8 Aug 2007, at 18:27, Dale Johannesen wrote: > Inserting a pseudo before your tail call that defines all the callee- > saved > registers should work. See FP_REG_KILL. the trick of dale seems to work with the downside that all registers are safed (and in llvm-2.0 the epilogue inserter ignoring the isTerminator instruction - note to myself: should move to trunk soon!) another option would be to do the move from the register holding the function pointer to...

...Loop Pass Manager > Loop Strength Reduction > Lower Garbage Collection Instructions > Remove unreachable blocks from the CFG > Optimize for code generation > Insert stack protectors > X86 DAG->DAG Instruction Selection > X86 FP_REG_KILL inserter > X86 Maximal Stack Alignment Calculator > <MY PASS RUNS HERE> > > >> Also, does bb.getBasicBlock() for sure always returns a valid block >> refrerence? > > Yes. I am printing bb and *bb.getBasicBlock() in order to compare the > content...

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

Hi, Shuguang Feng wrote: > Thanks for such a rapid response! > >> Don't know about Passes in the backend, but this could be a problem of >> an FunctionPassManager trying to use a ModulePass. > > I manually applied the patch you provided for llc (I'm using the 2.5 > release of LLVM not ToT) and it fixed my compilation error. When your > patch replaced the

Hello list, i am currently trying to implement tail call optimization in the X86 backend , so far i have it working for cases (modulo many unknown bugs :) where the tail called function is a destination within the source file and frame pointer elimination is performed. i implemented it as a dagcombiner transformation running in post legalized phase within the

> It *is* allowed to access ModulePass analysis information from an > FunctionPass? BasicBlockPlacement (a FunctionPass) also accesses the profile information and I assumed it worked (but haven't independently verified this). > Can you try to manually override the PI value in the > MyCodeGenPass::runOnMachineFunction() to the value seen in llc and then > access the

Thanks for such a rapid response! > Don't know about Passes in the backend, but this could be a problem of > an FunctionPassManager trying to use a ModulePass. I manually applied the patch you provided for llc (I'm using the 2.5 release of LLVM not ToT) and it fixed my compilation error. When your patch replaced the FunctionPassManager used by llc with a PassManager the error went

...lt;0xFF, MRM4r, (ops GR32:$dst), "jmp {*}$dst # > TAIL CALL jmpr", > []>; > > On 8 Aug 2007, at 18:27, Dale Johannesen wrote: >> Inserting a pseudo before your tail call that defines all the callee- >> saved >> registers should work. See FP_REG_KILL. > > the trick of dale seems to work with the downside that all registers > are safed (and in llvm-2.0 the epilogue inserter ignoring > the isTerminator instruction - note to myself: should move to trunk > soon!) > > another option would be to do the move from the register hold...

...dling preparation > Lower Garbage Collection Instructions > Remove unreachable blocks from the CFG > Optimize for code generation > Insert stack protectors > Machine Function Analysis > X86 DAG->DAG Instruction Selection > X86 FP_REG_KILL inserter ... Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately discarded, when the SelectionDAGISel kicks in the "No Profile Info"-Implementation is used: > 0x1c1a740...

Here's what's left on Linux (GCC 4.1.0), after all updates that went into the branch: Running /proj/llvm/build/../llvm/test/Regression/CFrontend/dg.exp ... FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-12- LargeAggregateCopy.c.tr: gccas: /proj/llvm/build/../llvm/lib/VMCore/Function.cpp:266: unsigned int llvm::Function::getIntrinsicID() const: Assertion `0 &&

...support meta labels!\n"); > + MCE.emitLabel(MI.getOperand(0).getImm()); > + break; > case X86::IMPLICIT_DEF_GR8: > case X86::IMPLICIT_DEF_GR16: > case X86::IMPLICIT_DEF_GR32: > @@ -613,7 +622,6 @@ > case X86::IMPLICIT_DEF_VR128: > case X86::FP_REG_KILL: > break; > -#endif > case X86::MOVPC32r: { > // This emits the "call" portion of this pseudo instruction. > MCE.emitByte(BaseOpcode); > @@ -627,7 +635,6 @@ > } > CurOp = NumOps; > break; > - > case X86II::RawFrm: >...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

...etAsmInfo(); > + FinalSize += AI->getInlineAsmLength(AsmStr); > + break; > + } > + case TargetInstrInfo::LABEL: > + break; > + case TargetInstrInfo::IMPLICIT_DEF: > + case TargetInstrInfo::DECLARE: > + case X86::DWARF_LOC: > + case X86::FP_REG_KILL: > + break; > + case X86::MOVPC32r: { > + // This emits the "call" portion of this pseudo instruction. > + ++FinalSize; > + FinalSize += sizeConstant(X86InstrInfo::sizeOfImm(Desc)); > + break; > + } > + } > + CurOp = NumOps;...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And