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