similar to: [LLVMdev] Stack alignment in JIT compiled code

Hello, Simon > So far, i found no way to denote calls to the host function as aligned > or maintain stack alignment throughout the stack frame of the jit > compiled function. Further, the gcc front end (llvm-g++ (GCC) 4.2.1) > seems to ignore directives such as -mpreferred-stack-boundary. Mike is right. It depends on your subtarget: 1. If you're running stuff on Darwin, which has

On Linux x86_64, it is different. The x86-64 ABI says (http://www.x86-64.org/viewvc/trunk/x86-64-ABI/low-level-sys-info.tex?revision=84&content-type=text%2Fplain): >> The end of the input argument area shall be aligned on a 16 byte boundary. In other words, the value (%rsp - 8) is always a multiple of 16 when control is transferred to the function entry point. The stack pointer, %rsp,

Using LLVM 2.9, the following LLVM IR produces invalid x86 32 bit assembly (a misaligned SSE store). ; ModuleID = 'MisalignedStore' define void @MisalignedStore() nounwind readnone { entry: %v = alloca <4 x float>, align 16 store <4 x float> zeroinitializer, <4 x float>* %v, align 16 br label %post-block post-block: %f = alloca float ret void } If I feed

I don't know how to file a PR, but I have a patch (see below), that should work regardless of abi differences, since it relies on the compiler to do the though job. void X86CompilationCallback_SSE(void) { char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned asm volatile ( "movl %%eax,(%0)\n" "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think

Hello, Corrado > Before you can correctly invoke a function via the Procedure Linkage > Table (plt), the ABI mandates that ebx is pointing to the GOT (Global > Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) This is known issue, just nobody realized, that we have bunch of non- PIC-aware assembler code. :) Fixing would be not so trivial though, mostly due to ABI

Hello. I found that the X86CompilationCallback_SSE wrapper for X86CompilationCallback2 is not setting up properly for the PIC invocation. Before you can correctly invoke a function via the Procedure Linkage Table (plt), the ABI mandates that ebx is pointing to the GOT (Global Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) Dump of assembler code for function

On Thu, Nov 10, 2011 at 6:13 PM, Aaron Dwyer <Aaron.Dwyer at imgtec.com> wrote: > Using LLVM 2.9, the following LLVM IR produces invalid x86 32 bit assembly > (a misaligned SSE store). > ; ModuleID = 'MisalignedStore' > define void @MisalignedStore() nounwind readnone { > entry: >   %v = alloca <4 x float>, align 16 >   store <4 x float>

Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0

On Oct 18, 2007, at 1:52 PM, Chuck Rose III wrote: > > Here are the instructions for evaluateDependents. The JITter > hasn’t compiled foo yet. What’s confusing to me is why did my > movups suddenly become a movaps? All the stores and loads have > align 1 on them. Hi Chuck, I believe this is a bug but am unable to reproduce it with the test case you've provided. I

Hello LLVMers, High order bit: Presence of a called function is causing a store on an unrelated vector to generate an aligned store rather an unaligned one despite unaligned store being indicated in the associated StoreInst. Details: I pulled down the latest source, so this is something I'm finding with the current LLVM. I'm hoping you'll have an idea what's

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

Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > >

On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > >> I've noticed that LLVM tends to generate suboptimal code and spill an >> excessive amount of registers in large functions, such as in those >> that are automatically generated by FFTW. >

On Sat, Jul 7, 2012 at 12:25 AM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: >>> [...] >>> movaps 32(%rdi), %xmm3 >>> movaps 48(%rdi), %xmm2 >>>

I have some programs crashing when I upgraded from clang 3.9.1 to clang 4.0.1. Debugging this I found the reason for the crash. This is happening in the following assembly fragment for a piece of code allocating a class object (size: 24 bytes) using operator new and then initializing it: 0x00002aaaafc145f3 <+35>: callq 0x2aaaafdf5f90 <operator new(unsigned long)>

Hi all, The InstructionCombining pass causes alignment of globals to be ignored. I've attached a replacement of Fibonacci.cpp which reproduces this (I used 2.3 release). Here's the x86 code it produces: 03C20019 movaps xmm0,xmmword ptr ds:[164E799h] 03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah] 03C20027 movaps xmmword ptr ds:[164E799h],xmm0 03C2002E

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > >

Hi, I've noticed that LLVM tends to generate suboptimal code and spill an excessive amount of registers in large functions, such as in those that are automatically generated by FFTW. LLVM generates good code for a function that computes an 8-point complex FFT, but from 16-point upwards, icc or gcc generates much better code. Here is an example of a sequence of instructions from a 32-point