similar to: [LLVMdev] Stack alignment on X86 AVX seems incorrect

On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: ... > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > confirms that the use of a frame-pointer is optional. > > So, if one doesn't use ENTER in the prologue and uses RSP to access local >

Cameron, Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not normative. See foot note 7 in the same page. Figure 3.4 on page 21 confirms that the use of a frame-pointer is optional. So, if one doesn't use ENTER in the prologue and uses RSP to access local variables, RBP may be used as a calee-saved GPR. -- Evandro Menezes Austin, TX emenezes at

On Fri, Mar 02, 2012 at 11:58:29AM -0500, Cameron McInally wrote: > On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> > wrote: > ... > > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > > confirms that the use of a frame-pointer is optional.

Hi Elena, You're correct. LLVM does not align the stack to 32-bytes for AVX and unaligned moves should be used for YMM spills. I wrote some code to align the stack to 32-bytes when AVX spills are present; it does break the x86-64 ABI though. If upstream would be interested in this code, I can arrange with my employer to send a patch to the mailing list. -Cameron On Mar 1, 2012, at 4:09 PM,

Cameron, Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach was taken for i386 in GCC in order to support SSE vectors. Perhaps you could elaborate where the ABI was violated when your patch is applied. HTH -- Evandro Menezes

On Thu, Mar 1, 2012 at 4:29 PM, Evandro Menezes <emenezes at codeaurora.org>wrote: ... > Aligning the stack to 32 bytes when there are auto AVX vector variables > present shouldn't necessarily break the x86-64 ABI, as long as smaller auto > variables remain properly aligned. A similar approach was taken for i386 > in GCC in order to support SSE vectors. > > Perhaps

I'd appreciate some help in figuring out how to determine which InstrItinClass an instruction belongs to. For example, an InstrItinClass is defined in Schedule.td as: def FOO : InstrItinClass; Which is then used to build an InstrItinData in ProcessorItineraries and to specify the class of a particular instruction. I'd like to find out from a given instruction which class it belongs

Hello, I believe MCInstrDesc::getSchedClass() is what you're looking for. -Jim On Nov 28, 2011, at 5:03 PM, Evandro Menezes wrote: > I'd appreciate some help in figuring out how to determine which > InstrItinClass an instruction belongs to. > > For example, an InstrItinClass is defined in Schedule.td as: > > def FOO : InstrItinClass; > > Which is then used

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables >> present shouldn't necessarily break the x86-64 ABI, as long as smaller auto >> variables remain properly aligned. A similar approach was taken for i386 >> in GCC in order to support SSE vectors. >>

Sebastian, If not a test, how about a patch in the documentation for TableGen about this new feature that you're making available? -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 06/20/12 16:02, Sebastian Pop wrote: > On Wed, Jun 20, 2012 at 3:40 PM, Villmow, Micah<Micah.Villmow at

On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > On 08/21/12 16:49, Jim Grosbach wrote: >> >> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. >> >> Beyond that, I don't see an alternative to an audit

Has anyone attempted the port of LLVM to a VLIW architecture? Is there any publication about it? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Two responses inline... My current thinking is that an emergency spill slot could be set aside to > hold the original, ABI conforming, frame pointer. Not an ideal solution, > but in my situation where I must cover any code a user throws at me, > breaking the ABI and playing with the stack is preferred. > > Ah, this is not a good idea. I examined this a while back. The issue is that

On Thu, Jun 21, 2012 at 10:31 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > Sebastian, > > If not a test, how about a patch in the documentation for TableGen about > this new feature that you're making available? That's a good point. I will prepare a patch for the docs. Thanks for your review! Sebastian -- Qualcomm Innovation Center, Inc is a member of

Owen, On 11/29/12 18:16, Owen Anderson wrote: >> Will the size of the >> packet be properly accounted for by the MCObjectStreamer if we have to pad >> the packet (mainly for fetch alignment)? > The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. Where could I

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

Folks, I'm at a loss trying to add Compiler-RT to an LLVM build, even after checking out the instructions at http://compiler-rt.llvm.org, so I'd appreciate your help. I've tried adding the CMake options LLVM_ENABLE_PROJECTS, LLVM_BUILD_EXTERNAL_COMPILER_RT, LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, CLANG_DEFAULT_RTLIB. All to no avail. FWIW, I'm building for the targets

Hi, I'm wondering how the Hexagon backend maps instructions to functional units after instructions have been grouped into packets. The order of instructions inside a packet appears to be random and the functional unit information has been lost. How does the code emitter know which functional unit an instruction is supposed to be dispatched to? Thanks, Tom