search for: analyzecalloperand

Displaying 8 results from an estimated 8 matches for "analyzecalloperand".

Did you mean: analyzecalloperands
2008 Dec 20
1
[LLVMdev] anybody working on ARM Cortex support?
On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you
2007 Jun 20
1
[LLVMdev] Calling Convention & Stack Frame
Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my
2007 Sep 11
0
[LLVMdev] RFC: Tail call optimization X86
...= 0; + SDOperand Callee = Op.getOperand(4); + //unsigned NumOps = (Op.getNumOperands() - 5) / 2; + + // Analyze operands of the call, assigning locations to each operand. + SmallVector<CCValAssign, 16> ArgLocs; + CCState CCInfo(CC, isVarArg, getTargetMachine(), ArgLocs); + CCInfo.AnalyzeCallOperands(Op.Val, CC_X86_32_TailCall); + if (isTailCall && + IsEligibleForTailCallElimination(Op, DAG,CC, Callee) && + PerformTailCallOpt) { IsEligibleForTailCallElimination() should be a target hook. This way TargetLowering::LowerCallTo() can determine whether a call is eli...
2007 Sep 06
2
[LLVMdev] RFC: Tail call optimization X86
Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in
2008 Dec 27
3
[LLVMdev] Using CallingConvLower in ARM target
...e AAPCS VFP variant calling conventions. Is there a >>> reason why the ARM Target isn't using the CCState machinery? >> >> Please clarify. I am not sure what you mean by CCState machinery. > > The ARM Target doesn't use the class CCState. For example, > CCState.AnalyzeCallOperands, CCState.AnalyzeCallReturn, > CCState.AnalyzeReturn, etc. There is no ARMCallingConv.td as there is > for other targets. All calling convention decisions are made manually. > > If there is no reason not to, it might simplify adding the AAPCS > Standard Variants like AAPCS-AFP, etc....
2007 Sep 11
2
[LLVMdev] RFC: Tail call optimization X86
...perand(4); > + //unsigned NumOps = (Op.getNumOperands() - 5) / 2; > + > + // Analyze operands of the call, assigning locations to each > operand. > + SmallVector<CCValAssign, 16> ArgLocs; > + CCState CCInfo(CC, isVarArg, getTargetMachine(), ArgLocs); > + CCInfo.AnalyzeCallOperands(Op.Val, CC_X86_32_TailCall); > + if (isTailCall && > + IsEligibleForTailCallElimination(Op, DAG,CC, Callee) && > + PerformTailCallOpt) { > > > IsEligibleForTailCallElimination() should be a target hook. This way > TargetLowering::LowerCallTo() can de...
2011 Jun 16
3
[LLVMdev] ARM support status (GHC/ARM new calling convention)
...from /lib/libc.so.1 #1 0xfed9b27c in thr_kill () from /lib/libc.so.1 #2 0xfed49f4a in raise () from /lib/libc.so.1 #3 0xfed2197c in abort () from /lib/libc.so.1 #4 0x08fc40fa in llvm::llvm_unreachable_internal (msg=0x0, file=0x0, line=0) at ErrorHandling.cpp:99 #5 0x08bcbf19 in llvm::CCState::AnalyzeCallOperands (this=0x8045c80, Outs=@0x8046350, Fn=0x88c7838 <ARM_AAPCS_GHC>) at CallingConvLower.cpp:126 #6 0x088cb08a in llvm::ARMTargetLowering::LowerCall (this=0x92b4c58, Chain= {Node = 0x92d1b50, ResNo = 0}, Callee={Node = 0x92d1c60, ResNo = 0}, CallConv=llvm::CallingConv::GHC, isV...
2018 Sep 14
6
Function calls keep increasing the stack usage
Hi everyone, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl