search for: callingconvlow

On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote: > Attached is a prototype patch that uses CCState to lower RET nodes in > the ARM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, so it should already be handled. > > > def

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>,

Greetings Sandeep I have tested crosscompiling llvm2.6 svn trunk 69279 + your patch for armv7a hardware. I wanted to see if it would build and if any unexpected failing tests in the testsuite would start to work using your patch. It built fine and your attached tests in the patch runs fine for me :) Now something fun this Generic test now works that previously failed: $ llvm-as <

On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote: > On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote: >> >> One problem with this approach is that since i64 isn't legal, the >> bitcast would require custom C++ code in the ARM target to >> handle properly. It might make sense to introduce something >> like >> >>

...value (see the StaticAllocaMap), and adjust the argument list and return code accordingly. For recognizing when an sret is needed, it'll be necessary to know what the target supports. This is described in the targets' *CallingConv.td files. Currently the consumer of this information is the CallingConvLowering code in include/llvm/CodeGen/CallingConvLower.h lib/CodeGen/SelectionDAG/CallingConvLower.cpp This code is currently used from within the target-specific code inside LowerFormalArguments and friends. However, it could also be called from the SelectionDAGBuild directly to determine if there a...

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote: > > One problem with this approach is that since i64 isn't legal, the > bitcast would require custom C++ code in the ARM target to > handle properly. It might make sense to introduce something > like > > CCIfType<[f64], CCCustom> > > where CCCustom is a new entity that tells the

Thanks Sandeep. I did a quick scan, this looks really good. But I do have a question: +/// CCCustomFn - This function assigns a location for Val, possibly updating +/// all args to reflect changes and indicates if it handled it. It must set +/// isCustom if it handles the arg and returns true. +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, + MVT

...e i32 @main(i32 %argc, i8** nocapture %argv) nounwind { entry: %0 = tail call i256 (...)* @get_num() nounwind ;comment here ret i32 0 } declare i256 @get_num(...) --------------------------------------------- First line of error: Call result #2 has unhandled type i64UNREACHABLE executed at CallingConvLower.cpp:148! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100525/5ba9a2bf/attachment.html>

I think I've got all the cases handled now, implementing with CCCustom<"foo"> callbacks into C++. This also fixes a crash when returning i128. I've also included a small asm constraint fix that was needed to build newlib. deep On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:

...; or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :) > So: > > 1. Calling conventions > Partly tablegen / partly C++ code. Look for > CodeGen/SelectionDAG/CallingConvLower.cpp, > Target/X86/X86CallingConv.td and around. Usually this code is run > during different phases of sdag lowering. > > 2. Prologue / epilogue. > Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite > obviously, right?) with bunch of target-specialized hooks, for &g...

On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: > Although it's not generally needed for ARM's use of CCCustom, I return > two bools to handle the four possible outcomes to keep the mechanism > flexible: > > * if CCCustomFn handled the arg or not > * if CCCustomFn wants to end processing of the arg or not +/// CCCustomFn - This function assigns a location for Val,

...n mdbx.f90 confuses dragoneg 13561 - LLVM ERROR: Cannot select: 0x14214bb10: i16 = extract_vector_elt 0x14214b910, 0x142142c10 14116 - Inliner incorrectly combines cleanup and catch landing pads 14279 - mishandling of implicit move in class with copy-only member 14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning v4f64 on ARM 14429 - Dragonegg fails to build clang Pawel

On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: >> >>> Although it's not generally needed for ARM's use of CCCustom, I >>> return >>> two bools to handle the four possible outcomes to keep

...s generated, is it bespoke C++ code > or TableGen generated ? > > If someone could point me in the right direction please. Calling convention is really-really far from prologue/epilogue emission :) So: 1. Calling conventions Partly tablegen / partly C++ code. Look for CodeGen/SelectionDAG/CallingConvLower.cpp, Target/X86/X86CallingConv.td and around. Usually this code is run during different phases of sdag lowering. 2. Prologue / epilogue. Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite obviously, right?) with bunch of target-specialized hooks, for example, ones located in Target...

...0 PM, Andreas Färber wrote: > Hello, > > Running the Debug+Asserts version instead of the Release should give you the file and line of the "unreachable" code. > > Andreas Thanks for the suggestion. I recompiled with Debug+Asserts and it shows that the unreachable is in CallingConvLower.cpp:162. Here is the error message: Call result #2 has unhandled type f32UNREACHABLE executed at CallingConvLower.cpp:162! I don't think my backend is modified enough from the MBlaze backend that is in the release to be causing this error. I am however looking through the various files of t...

...> define internal fastcc <4 x float> @add(<4 x float> %a.val, <4 x float> > %b.val) nounwind { > entry: > %tmp4 = fadd <4 x float> %a.val, %b.val > ret <4 x float> %tmp4 > } That I don't know, but I'd look around TargetCallingConv.td, CallingConvLower.h, etc. -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...y: > > %0 = tail call i256 (...)* @get_num() nounwind ;comment here > ret i32 0 > } > > declare i256 @get_num(...) > > --------------------------------------------- > > First line of error: > > Call result #2 has unhandled type i64UNREACHABLE executed at CallingConvLower.cpp:148! > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Although it's not generally needed for ARM's use of CCCustom, I return two bools to handle the four possible outcomes to keep the mechanism flexible: * if CCCustomFn handled the arg or not * if CCCustomFn wants to end processing of the arg or not I placed the "unsigned i" outside those loops because i is used after the loop. If there's a better index search pattern, I'd

...or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue > emission :) So: > > 1. Calling conventions > Partly tablegen / partly C++ code. Look for > CodeGen/SelectionDAG/CallingConvLower.cpp, > Target/X86/X86CallingConv.td and around. Usually this code is run > during different phases of sdag lowering. > > 2. Prologue / epilogue. > Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite > obviously, right?) with bunch of target-specialized hooks, for &g...