Displaying 6 results from an estimated 6 matches for "analyzereturn".
2008 Dec 27
3
[LLVMdev] Using CallingConvLower in ARM target
...>>,
CCIfType<[i64], CCExtractElements<2, i32>>,
CCIfType<[i32], CCAssignToReg<[R0, R1]>>
]>;
The problem is that i64 handling requires splitting into 2 x i32
registers. I am not sure how to build CCExtractElements as shown. The
current organization of CCState::AnalyzeReturn does not allow for
reissuing of the RET with an altered set of operands which is the
solution used elsewhere. Can anyone suggest a better way to express
this lowering?
Deep
On Fri, Dec 19, 2008 at 6:43 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> On Fri, Dec 19, 2008 at 4:54 P...
2009 Jun 25
1
[LLVMdev] Structure Returns
...t it gave me an
assertion failure when I was trying to compile the resulting bitcode.
Specifically, I had following function definition
define {i32,i32,i32} @func(i32 a)
{
.....
ret {i32,i32,i32} %retStruct
}
llc gave me following assertion failure:
Return operand#2 has unhandled type i32 in AnalyzeReturn function
On digging out from LLVM website, I found
"Note that the code generator does not yet fully support large return
values. The specific sizes that are currently supported are dependent on the
target. For integers, on 32-bit targets the limit is often 64 bits, and on
64-bit targets the...
2009 Jan 03
0
[LLVMdev] Using CallingConvLower in ARM target
...CExtractElements<2, i32>>,
>
> CCIfType<[i32], CCAssignToReg<[R0, R1]>>
> ]>;
>
> The problem is that i64 handling requires splitting into 2 x i32
> registers. I am not sure how to build CCExtractElements as shown. The
> current organization of CCState::AnalyzeReturn does not allow for
> reissuing of the RET with an altered set of operands which is the
> solution used elsewhere. Can anyone suggest a better way to express
> this lowering?
One problem with this approach is that since i64 isn't legal, the
bitcast would require custom C++ code in the...
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
2013 Feb 02
0
[LLVMdev] Moving return value registers from MRI to return instructions
...should add return value registers to the RET_FLAG node instead of calling MRI.addLiveOut():
--- a/lib/Target/X86/X86ISelLowering.cpp
+++ b/lib/Target/X86/X86ISelLowering.cpp
@@ -1590,14 +1590,7 @@ X86TargetLowering::LowerReturn(SDValue Chain,
RVLocs, *DAG.getContext());
CCInfo.AnalyzeReturn(Outs, RetCC_X86);
- // Add the regs to the liveout set for the function.
- MachineRegisterInfo &MRI = DAG.getMachineFunction().getRegInfo();
- for (unsigned i = 0; i != RVLocs.size(); ++i)
- if (RVLocs[i].isRegLoc() && !MRI.isLiveOut(RVLocs[i].getLocReg()))
- MRI.addLiveOut...