search for: callingconvlowering

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 are su...

> 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

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

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:

On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > Hello, Aaron > > > How/where are function prologs and epilogs 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 :)

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,

Hello, Just a quick reminder that the November 29th (10p.m. PST) is the end of Phase 1 testing and Release Candidate 2 (RC2) deadline. After RC2 deadline, LLVM-Clang 3.2 release will be considered feature complete and no new functionality can be added. With 2 days left please use following guidelines when initiating request for patches before RC2 deadline. I will be happy to merge *approved*

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

Hello, Aaron > How/where are function prologs and epilogs 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,

On Mar 15, 2011, at 1:50 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

On 9/5/2012 5:02 PM, Khaled Mohammed wrote: > How about vector parameters? > > 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,

On May 25, 2010, at 5:16 PM, Ehsan Amiri wrote: > Hello all > > I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. This works for me on mainline.

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

On Apr 9, 2009, at 11:11 AMPDT, Aaron Gray wrote: > On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info > > wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it > bespoke C++ code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling