search for: stackptr

...emory" ); asm volatile ( // Save all XMM arg registers "movaps %%xmm0, (%0)\n" "movaps %%xmm1, 16(%0)\n" "movaps %%xmm2, 32(%0)\n" "movaps %%xmm3, 48(%0)\n" :: "r"(SAVEBUF) : "memory" ); intptr_t *StackPtr=0, RetAddr=0; asm volatile ( // get stack ptr and retaddr "movl %%ebp,%0\n" "movl 4(%%ebp),%1\n" :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); X86CompilationCallback2(StackPtr,RetAddr); // gcc knows how to call this accordi...

...// Arguments that can be passed in a register must be kept in the // RegsToPass vector. if (VA.isRegLoc()) { RegsToPass.push_back(std::make_pair(VA.getLocReg(), Arg)); } else { // Sanity check. assert(VA.isMemLoc()); // Get the stack pointer if needed. if (StackPtr.getNode() == 0) { StackPtr = DAG.getCopyFromReg(Chain, dl, ARC::SP, getPointerTy()); } SDValue PtrOff = DAG.getNode(ISD::ADD, dl, getPointerTy(), StackPtr, DAG.getIntPtrConstant(VA.getLocMemOffset())); MemOpChains.push_back(DAG.getStore(Chain, dl, Arg, PtrOff,...

...e need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); > } I assume that we need the opposite - if (.. < 8) getExtLoad // VT should be MVT::i8, MemVT should be MVT::i1 else getLoad -...

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

...I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); } else { return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); } How do you think about it? Thanks, JinGu Kang On 15/09/2017 18:42, Demikhovsky, Elena wrote: extends the elements to 8bit and stores them on stack....

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

...sed +/// instruction if it is an ADD instruction it is deleted and the size is +/// returned +static int32_t CheckAndDeletePreceedingADD(MachineBasicBlock::iterator MBBI, + MachineBasicBlock &MBB, + unsigned StackPtr) { + int32_t Offset = 0; + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned Opc = PI->getOpcode(); + if ((Opc == X86::ADD64ri32 || Opc == X86::ADD64ri8 || + Opc == X86::ADD32ri || Opc == X86::ADD32ri8) && + PI->getOperand(...

...( > // Save all XMM arg registers > "movaps %%xmm0, (%0)\n" > "movaps %%xmm1, 16(%0)\n" > "movaps %%xmm2, 32(%0)\n" > "movaps %%xmm3, 48(%0)\n" > :: "r"(SAVEBUF) : "memory" ); > > intptr_t *StackPtr=0, RetAddr=0; > > asm volatile ( // get stack ptr and retaddr > "movl %%ebp,%0\n" > "movl 4(%%ebp),%1\n" > :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); > > X86CompilationCallback2(StackPtr,RetAddr); // gcc kn...

...ack pointer tracking ability. if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { unsigned Opc = (CalleeAmt < 128) ? (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); MachineInstr *New = BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm (CalleeAmt); MBB.insert(I, New); } } I am not sure about a command line switch would toggling the stack adjusting behaviour of a function. Because if the function is called from a different module which was compiled with the opposite command line swit...

...( > // Save all XMM arg registers > "movaps %%xmm0, (%0)\n" > "movaps %%xmm1, 16(%0)\n" > "movaps %%xmm2, 32(%0)\n" > "movaps %%xmm3, 48(%0)\n" > :: "r"(SAVEBUF) : "memory" ); > > intptr_t *StackPtr=0, RetAddr=0; > > asm volatile ( // get stack ptr and retaddr > "movl %%ebp,%0\n" > "movl 4(%%ebp),%1\n" > :"=r"(StackPtr), "=r"(RetAddr) :: "memory" ); > > X86CompilationCallback2(StackPtr,RetAddr); // gcc kn...

.../ Calculate and remember argument location. + else + CalculateTailCallArgDest(DAG, MF, isPPC64, Arg, SPDiff, ArgOffset, + TailCallArguments); + ... - // We are emitting Altivec params in order. - PtrOff = DAG.getNode(ISD::ADD, PtrVT, StackPtr, - DAG.getConstant(ArgOffset, PtrVT)); - SDOperand Store = DAG.getStore(Chain, Arg, PtrOff, NULL, 0); - MemOpChains.push_back(Store); + if (!isTailCall) { + // We are emitting Altivec params in order. + PtrOff = DAG.getNode(ISD::ADD,...

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

...t; + else > + CalculateTailCallArgDest(DAG, MF, isPPC64, Arg, SPDiff, > ArgOffset, > + TailCallArguments); > + > ... > - // We are emitting Altivec params in order. > - PtrOff = DAG.getNode(ISD::ADD, PtrVT, StackPtr, > - DAG.getConstant(ArgOffset, PtrVT)); > - SDOperand Store = DAG.getStore(Chain, Arg, PtrOff, NULL, 0); > - MemOpChains.push_back(Store); > + if (!isTailCall) { > + // We are emitting Altivec params in order. > +...

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

Here is a patch to improve argument lowering for tail calls. Before this patch all outgoing arguments were move to the stack slot where they would go on a normal function call and from there moved back to the tail call stack slot to prevent overwriting of values. After this patch only arguments that source from callers arguments (formal_arguments) are lowered this way. I moved some code

> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question

...stub or call site and pass it into the JIT /// compiler function. extern "C" { +LLVM_ATTRIBUTE_USED // Fix gcc -flto builds. gcc's LTO (as of 4.8.1) don't sees + // references from inline asm. LLVM_LIBRARY_VISIBILITY void LLVMX86CompilationCallback2(intptr_t *StackPtr, intptr_t RetAddr) { intptr_t *RetAddrLoc = &StackPtr[1]; (However, I still can't link unittest programs, because of the use of anchor methods in CommandLine. I will take a look at it shortly.) /Patrik Hägglund -----Original Me...

...ng %rsp. - if (isSPUpdateNeeded) { + if (Is64Bit) { + // MSVC x64's __chkstk and cygwin/mingw's ___chkstk_ms do not adjust %rsp + // themself. It also does not clobber %rax so we can reuse it when + // adjusting %rsp. BuildMI(MBB, MBBI, DL, TII.get(X86::SUB64rr), StackPtr) .addReg(StackPtr) .addReg(X86::RAX) .setMIFlag(MachineInstr::FrameSetup); } - if (isEAXAlive) { // Restore EAX MachineInstr *MI = addRegOffset(BuildMI(MF, DL, TII.get(X86::MOV32rm), diff --git a/test/CodeGen/X86/win64_alloca_dynalloca.ll b/tes...

...> if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { > unsigned Opc = (CalleeAmt < 128) ? > (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : > (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); > MachineInstr *New = > BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm > (CalleeAmt); > MBB.insert(I, New); > } > } > > I am not sure about a command line switch would toggling the stack > adjusting behaviour of a function. Because if the function is called > from a different module which was compiled wit...

..._t CalleeAmt = I->getOperand(1).getImm()) { >> unsigned Opc = (CalleeAmt < 128) ? >> (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : >> (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); >> MachineInstr *New = >> BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm >> (CalleeAmt); >> MBB.insert(I, New); >> } >> } >> >> I am not sure about a command line switch would toggling the stack >> adjusting behaviour of a function. Because if the function is called >> from a differe...