similar to: [LLVMdev] stack alignment restriction

Thanks for the answer.. A followup question - Is this already taken into consideration when generating address calculation offset etc or would this need to be specially taken care? I am assuming all load/stores also would need to be custom lowered. thanks dz On Wed, Dec 29, 2010 at 5:45 AM, Bill Wendling <wendling at apple.com> wrote: > On Dec 28, 2010, at 4:02 PM, drizzle drizzle

On Dec 28, 2010, at 4:02 PM, drizzle drizzle wrote: > Hi > Is there a way to enforce a different alignment on vales on stack > as compared to other basic types. Particularly, i would like > characters to be stored at 2 byte boundary. > Check out examples in the lib/Target/* directories. For instance in X86CallingConv.td, we have things like this: def CC_X86_64_C :

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

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Thanks. More questions :-) /// Information about how the value is assigned. - LocInfo HTP : 7; + LocInfo HTP : 6; Do you know why this change is needed? Are we running out of bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; -

On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: > /// Information about how the value is assigned. > - LocInfo HTP : 7; > + LocInfo HTP : 6; > > Do you know why this change is needed? Are we running out of bits? HTP was't using all of these bits. I needed the hasCustom bit to come from somewhere unless we wanted to grow this struct, so I

This time with the test cases actually attached. deep On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: >> /// Information about how the value is assigned. >> - LocInfo HTP : 7; >> + LocInfo HTP : 6; >> >> Do you know why this change

I'm not currently setup to be able to run the A/B comparison tests that test-suite relies upon. Fhourstones-3.1 looks to be the simplest. If you can send me the two .o files from either EABI or Darwin, I can dig into why this went wrong for you. deep On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: > Sorry I haven't gotten back to you earlier. I have

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

After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel

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,

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

Sorry I haven't gotten back to you earlier. I have been busy. I ran some MultiSource/Benchmark earlier today. Looks like there are some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/ consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and sim. Are you able to test them on your end? Evan On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: > This time with

Hi, all On the website, it says, CCAssignToRegWithShadow <registerList, shadowList> — similar to CCAssignToReg, but with a shadow list of registers 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, CCIfType<[i32], CCIfAlign<"8",

On Apr 16, 2009, at 2:52 AM, Sandeep Patel wrote: > After wasting an inordinate amount of time trying to get test-suite to > run on arm-apple-darwin so I could reproduce your results, attached is > a patch that fixes the small copy&paste error of having 8-byte > alignment for stack-allocated f64s instead of the proper 4-byte. I've > updated the patch to the top of trunk

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,

Hi, Clang crashes when below snippet of code is compiled (used latest svn version) *double func1() { double x ;* * asm ( "" : "=r"(x) : "0"(x) ); return x; }* > *clang -S test1.c* > *Assertion failed: (PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!", file

Done! Sandeep, this is really a great change. I had seen the discussion of it but hadn't looked at the details until now. Thanks a lot for contributing this. While I was reviewing it, I found some a few small nit-picky things to clean up (mostly in comments and whitespace). Sorry -- I'm a bit compulsive that way! I will commit those changes in a few minutes. Other than

Hi AArch64 experts - I'm working on a DAGCombiner patch, and it causes a change in an existing regression test. We're generating this: ext v0.16b, v1.16b, v1.16b, #8 Rather than this: mov d0, v1.d[1] Are those logically equivalent? Is one form preferred over the other? This is the IR test case in /test/CodeGen/AArch64/neon-scalar-copy.ll: define <1 x i64>

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