search for: fp_reg_kil

Displaying 16 results from an estimated 16 matches for "fp_reg_kil".

Did you mean: fp_reg_kill
2005 May 13
1
[LLVMdev] gmake check failures on FreeBSD
.../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:
2009 Sep 10
0
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
...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 targ...
2007 Aug 08
0
[LLVMdev] Destination register needs to be valid after callee saved register restore when tail calling
...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 t...
2009 Sep 10
2
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
...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 > conten...
2007 Aug 08
4
[LLVMdev] Destination register needs to be valid after callee saved register restore when tail calling
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
2009 Sep 10
1
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
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
2007 Aug 08
1
[LLVMdev] Destination register needs to be valid after callee saved register restore when tail calling
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
2009 Sep 10
0
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
> 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
2009 Sep 09
2
[LLVMdev] [PATCH] & Question: Preserving ProfileInfo for backend.
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
2007 Aug 09
1
[LLVMdev] Destination register needs to be valid after callee saved register restore when tail calling
...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 hol...
2009 Nov 17
2
[LLVMdev] PassManager again...
...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: > 0x1c1a74...
2006 Apr 13
3
[LLVMdev] Re: Creating Release 1.7 Branch at 1:00pm PDT
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 &&
2008 Feb 04
0
[LLVMdev] Exception handling in JIT
...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: >...
2008 Feb 01
2
[LLVMdev] Exception handling in JIT
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:
2008 Apr 16
0
[LLVMdev] Being able to know the jitted code-size before emitting
...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;...
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
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