similar to: [LLVMdev] What CCAssignToXXXWithShadow means?

Hello >  I don't know when we should use CCAssignToRegWithShadow. Because > I am not a architecture expert, please bear with my naive question. > Take ARMCallingConv.td as an example, ARM is not good example :) Look into win64 calling convention. Shadow means if some register is allocated for incoming argument another one cannot be used for argument allocation. On Win64 general

Hi, Anton > On Win64 general purpose registers shadow xmm and vice versa, so, say, > if you put argument into ecx, the xmm0 is marked as already occupied, > if you put argument into xmm1, edx is marked as occupied, etc. I think ecx and xmm0 are physical different registers (not like ecx and cx), right? So why we cannot use xmm0 while ecx has been used? Is it just a rule or there are

Hi, While working on adding newlib to my backend I hit the following assert : Assertion failed: BestRC && "Couldn't find the register class", file TargetRegisterInfo.cpp, line 112 The following llvm causes this : define void @specialBreak(i8* %out) nounwind { entry: %out.addr = alloca i8*, align 4 store i8* %out, i8** %out.addr, align 4 %0 = load i8** %out.addr,

Hi Karel, I understand this patch has already been merged (to 3.0), so don't take my question as stopping the merge to head, I'm just making sure I got it right... The rest looks correct. + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22,

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>>,

Hello Aaron, Anton, LLVM-dev, While working on http://llvm.org/PR13676#c6 I found out that whenever I compile code with class methods returning structures it get generated incompatible with MSVC. Looking at lib/Target/X86/X86CallingConv.td, I found out that CC_X86_32_ThisCall maps SRet to EAX but in fact it should push the address of the return temp on stack. The following patch fixes the issue

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 the mechanism >> flexible: >> >> * if CCCustomFn handled the arg or not >>

Hello, first of all: one of the LLVM 3.0 new feature was a support for GHC specific calling convention on ARM platform. It looks like this support was merged just into 3.0 branch, specifically it appeared in 3.0 RC2. Anyway, I hope this is just a mistake or omission that such support was merged only into 3.0 and not also into HEAD. I've just found it by testing LLVM 3.1 with GHC 7.4.2 and

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

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

So I thought I'd try to use the documentation on llvm backends to try to create a DLX backend. I think I've got most of the stuff for the .td files done but I've got some problems. * Do I need to represent the PC in my XXXRegisterInfo.td file; the branch instruction effects it but you can directly access it ... I'm thinking not. * In my Instruction subclasses (in

ARMTargetLowering doesn't need case #1, but it seemed like you and Dan wanted a more generic way to inject C++ code into the process so I tried to make the mechanism a bit more general. deep On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > >> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng

On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > ARMTargetLowering doesn't need case #1, but it seemed like you and Dan > wanted a more generic way to inject C++ code into the process so I > tried to make the mechanism a bit more general. Ok. Since ARM doesn't need it and it's the only client, I'd much rather have CCCustomFn just return a single bool indicating

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

Sure. Updated patches attached. deep On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > >> ARMTargetLowering doesn't need case #1, but it seemed like you and Dan >> wanted a more generic way to inject C++ code into the process so I >> tried to make the mechanism a bit more

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 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,

Sorry left a small bit of cruft in ARMCallingConv.td. A corrected patch it attached. deep On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > Sure. Updated patches attached. > > deep > > On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:

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 >> >>