similar to: [LLVMdev] stack alignment restriction

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] stack alignment restriction"

2010 Dec 29
1
[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
2010 Dec 29
0
[LLVMdev] stack alignment restriction
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 :
2012 Oct 02
4
[LLVMdev] Handling SRet on Windows x86
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
2013 Sep 25
1
[LLVMdev] arm64 / iOS support
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,
2009 Feb 16
3
[LLVMdev] Using CallingConvLower in ARM target
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; -
2009 Feb 18
0
[LLVMdev] Using CallingConvLower in ARM target
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
2009 Feb 18
2
[LLVMdev] Using CallingConvLower in ARM target
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
2009 Feb 28
3
[LLVMdev] Using CallingConvLower in ARM target
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
2008 Dec 27
3
[LLVMdev] Using CallingConvLower in ARM target
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>>,
2009 Apr 16
2
[LLVMdev] Using CallingConvLower in ARM target
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
2013 Apr 24
1
[LLVMdev] Backend : What am I missing here
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,
2009 Jan 03
0
[LLVMdev] Using CallingConvLower in ARM target
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
2009 Feb 26
0
[LLVMdev] Using CallingConvLower in ARM target
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
2011 Sep 23
2
[LLVMdev] What CCAssignToXXXWithShadow means?
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",
2009 Apr 17
0
[LLVMdev] Using CallingConvLower in ARM target
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
2012 Jun 24
0
[LLVMdev] Request for merge: GHC/ARM calling convention.
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,
2012 Nov 20
2
[LLVMdev] Extended Inline asm with double data type crashes clang
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
2009 Apr 17
1
[LLVMdev] Using CallingConvLower in ARM target
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
2014 Dec 11
2
[LLVMdev] AArch64 codegen question
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>
2012 Jun 24
4
[LLVMdev] Request for merge: GHC/ARM calling convention.
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