similar to: [LLVMdev] Stack realignment

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

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

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

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

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

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

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

Hello, Everyone. Just few notes for everyone, who wants to build Qt with llvm. Everything was tested with shiny-new Qt 4.2.2 (X11 version) and llvm-gcc4 & LLVM from head. Instructions written here should also work on 1.9 release, as I've tested Qt build last time just before 1.9 release. 1. Specs Qt uses it's own configuration and build system called "qmake". We should

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

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

I'm getting this messages trying to call with one sip trunk: Feb 3 16:43:09 DEBUG[3389] channel.c: Avoiding initial deadlock for 'SIP/usa-e2ea' Feb 3 16:43:09 VERBOSE[3491] logger.c: -- SIP/usa-e2ea answered Zap/1-1 Feb 3 16:43:09 WARNING[3491] channel.c: No path to translate from Zap/1-1(68) to SIP/usa-e2ea(256) Feb 3 16:43:09 WARNING[3491] app_dial.c: Had to drop call

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

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.

Vikram, > I didn't know that EQUIVALENCE is the only unsupported major Fortran > feature, as this bug says. Can you give me an update on the status of > the Fortran front-end and what the near-term goals are? Ok. I was going to post something soon after 2.2 release, but let's do it now. LLVM 2.2 will contain (as a part of llvm-gcc 4.2) a port of gfortran compiler to the LLVM

Hello, all. Just found this file in my e-mail atchive, hope it will be useful for somebody. ===cut=here=== Some small rules: 1) No blankspace in the paths to the top-level directories. 2) Add paths to binaries to your system PATH variable. 3) Use short paths to top-level directories. 1. Some checks & preparations. 1) Be sure, that you're using right make version: $ make

Hi, Anyone is using LG ip phone LIP-100 with Asterisk. I've two of this phones but seems to work only with net2phone, in the product page http://isupport.lge.co.kr/html/ibu_lgic_modelView.jsp?jgrcode=D2_IPTP&modelid=M_IP100C the features are showing SIP and H.323 support. Can be used with my asterisk box? Best regards, -- Guillermo Salas M. Telconet S.A. Manta Calle 15 y Av. 24 Esq.

Hello, Greg. You wrote Saturday, May 6, 2006, 10:24:16 PM: GP> If anyone has any insight I'd love to hear it. GP> Meanwhile, I'll continue to investigate... Currently I'm working on bootstrapping llvm-gcc4 on mingw32 platform. There are some serious miscompartibilities preventing build. I'll let know the results. Anyway, it's common knowledge, that msys itself have

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru