Displaying 8 results from an estimated 8 matches for "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
elig...
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. s...
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 det...
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, isVa...
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