similar to: [LLVMdev] Passing pointers to pointers to JIT

Hey, we're trying to pass multidimensional arrays to JIT where one of the helper functions should convert them to LLVM vector types. Unfortunately passing a multidimensional array seems to crash the JIT and I'm not sure why. As an example, we have a file with two silly C functions: http://ktown.kde.org/~zrusin/llvm/llvm.c Both clang (latest svn) and llvm-gcc (4.0.1) produce basically

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem

Hello, Andrew > That's right.  If you want to be able to call any code produced by gcc, > you have to preserve 16-alignment.  gcc-generated code does not realign > the stack pointer. This was for gcc < 4.4, where stack alignment handling was really messy. stack-realignment branch was merged afair into gcc 4.4 and allows automatic realignment of stack, when necessary. -- With

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,

Hello > We are running llvm jit x86 on MS Visual Studio 2005. It seems there > is a bug in asm code in function X86CompilationCallback in file > X86JITInfo.cpp. Current code sets stack pointer to invalid value in > instruction "and   esp,  16". Depending on current stack pointer value > it sometimes overwrites ecx and edx registers with next three lines. How so? The stack

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

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov

Corrado Zoccolo wrote: > 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

Joerg, > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to > decide when to keep a reference in register and when not. It also reuses > existing functionality as much as possible. It does not seem to be enough. Even is there are *no* allocas in the function the stack realignment might still be

Hi Anton, Thanks for your questions, that's what I'm looking for. On Thu, Feb 26, 2009 at 5:33 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello, John > > > My limited implementation uses a workaround that adjusts the > > generation of prologue code and the frame indices used by > > the target eliminateFrameIndex() when necessary. I am

On Tue, Oct 23, 2012 at 12:56 PM, Eric Christopher <echristo at gmail.com>wrote: > > Thanks for replying so quickly. Would you elaborate on this further? > > > > It seems costly to change the default stack alignment on the platform, > since > > that would require recompiling all of the system and user libraries to > also > > adhere to 32-byte stack

Hello, Everyone. I've just checked code for dynamic stack realignment. This is needed on targets, where ABI-defined stack alignment is not so big (e.g. x86-32/linux, mingw32, cygwin, etc), but some stack objects (e.g. vectors) will require higher alignment. I think, I checked all 'hard' situations and code also survived llvm-gcc bootstrap, Qt, Mozilla, Manta compilation, but please

Hello, John > My limited implementation uses a workaround that adjusts the > generation of prologue code and the frame indices used by > the target eliminateFrameIndex() when necessary. I am looking at > several approaches, but I would like input from anyone who > has an opinion. I haven't looked into the patch deep enough yet, but I have at least 2 questions: 1. How do all the

> Thanks for replying so quickly. Would you elaborate on this further? > > It seems costly to change the default stack alignment on the platform, since > that would require recompiling all of the system and user libraries to also > adhere to 32-byte stack alignment. Depending on an alignment not specified > by the ABI would also limit our compiler's interoperability with

After having spoken to Johannes, I think we had a classic misunderstanding on what "extending" means. 1. The most obvious why for me was changing GEP to allow variable-sized multi-dimensional arrays in the first argument, such as %1 = getelementptr double, double* %ptr, inrange i64 %i, inrange i64 %j (normally GEP would only allow a single index argument for a pointer-typed base

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

On Sun, 15 Apr 2012 20:02:36 +0000 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi Hal! > > This is great! Vector-selects are always profitable compared to > scalar selects. They are even emulated using a few Xor/And/Or > instructions on platforms that don't have a native 'blend' support. > > Vector-geps on the other hand are only useful

On Mon, 21 Feb 2005, Jeff Cohen wrote: >>> trying out the really big array. You're right, it does clean it up except >>> for the multiplication. >>> >>> So LoopStrengthReduce is not ready for prime time and doesn't actually get >>> used? >> >> >> I don't know what the status of it is. You could try it out, and see

On Fri, 20 Apr 2012 13:02:29 -0500 <dag at cray.com> wrote: > Hal Finkel <hfinkel at anl.gov> writes: > > >> Vector-geps on the other hand are only useful in very specific > >> cases. > > > At the moment, the only cases where I've seen these vectorized in > > the current implementation is where some vectorizable integer > >

Hello, Ashwin. You wrote Wednesday, May 24, 2006, 11:25:11 AM: AC> "Pass::getClassPassInfo<PassClass>() "Pass class not AC> registered!"" failed: file AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", line 76 AC> Aborted Same for me. AC> Wihtout the -march specified (using native x86 assembly) it does AC> convert it into