similar to: [LLVMdev] Interaction of stacksave/restore and stack spills

Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] Interaction of stacksave/restore and stack spills"

2012 Feb 01
3
[LLVMdev] Issues with the llvm.stackrestore intrinsic
Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff
2012 Feb 03
0
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does
2013 Jul 25
4
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is
2018 May 11
0
best way to represent function call with new stack in LLVM IR?
On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > In the Zig frontend, we know at compile-time the entire call graph. > This means we know stack size for all functions and therefore the > upper bound stack usage. > > [snip] > 1. Is there a way to accomplish this with existing LLVM API? You should use the @llvm.stacksave and @llvm.stackrestore intrinsic. It is only legal
2013 Jul 30
0
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
How do you handle this during codegen? One problem is avoid stack changes (like spills). Another is coordinating things that are using allocas and those that are not but end up in the stack. Consider void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor argn, int argp1...) You will need an alloca for argn, but the ABI also requires it to be next to the plain integers that
2018 Apr 09
2
Issue with shrink wrapping
Hello, So, I have this testcase: void f(int n, int x[]) { if (n < 0) return; int a[n]; for (int i = 0; i < n; i++) a[i] = x[n - i - 1]; for (int i = 0; i < n; i++) x[i] = a[i] + 1; } that, compiled with -O1/-Os for AArch64 and X86, generates machine code, which fails to properly restore the stack pointer upon function return.
2011 Nov 02
1
[LLVMdev] [LLVMDev]: UNREACHABLE executed!
Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void
2020 Jun 25
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
Bringing this back up for discussion on handling exceptions. According to the inalloca design <https://llvm.org/docs/InAlloca.html>, there should be a stackrestore after an invoke in both the non-exceptional and exceptional case (that doesn't seem to be happening in some cases as we've seen, but that's beside the point). Does it make sense to model a preallocated call as
2018 May 11
1
best way to represent function call with new stack in LLVM IR?
On Thu, May 10, 2018 at 10:35 PM, whitequark <whitequark at whitequark.org> wrote: > On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > >> In the Zig frontend, we know at compile-time the entire call graph. >> This means we know stack size for all functions and therefore the >> upper bound stack usage. >> >> [snip] >> 1. Is there a way to
2015 Nov 23
2
asan for allocas on powerpc64
Jay, do you have a PowerPC64 target? If so, could you please check attached patch on PPC box? This is a draft patch, but it would be nice to make sure that we are moving to right direction here. Thanks, -Maxim On 18/11/15 00:12, Jay Foad wrote: >>> Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for >>> powerpc64. I've had a look at why it
2013 Oct 22
1
[LLVMdev] Starting implementation of 'inalloca' parameter attribute for MS C++ ABI pass-by-value
I wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll
2009 Jun 18
0
[LLVMdev] Explicitly Freeing Allocas
Nyx wrote: > Hello, > > I would just like to ask if it's possible to explicitly free allocas. This > is because I need to call functions that take structs of different sizes as > input, (possibly inside of loops) and I would rather avoid a stack overflow. You can't explicitly free a specific alloca, but you can use the llvm.stacksave and llvm.stackrestore intrinsics to
2015 Nov 23
2
asan for allocas on powerpc64
In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run. So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.) Jay. On 23 November 2015 at 13:07, Jay Foad
2015 Nov 17
3
asan for allocas on powerpc64
Hi! Sorry for delay, just returned from vacation. On 12/11/15 23:44, Kostya Serebryany via llvm-dev wrote: > +Maxim and Yuri, as I think this is their code. > > On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com > <mailto:jay.foad at gmail.com>> wrote: > > (Resending with the correct mailing list address.) > > Hi, > > Currently
2009 Jun 18
1
[LLVMdev] Explicitly Freeing Allocas
What kind of overhead does that have? Does it only restore the stack pointer to what it was (what I want), or does it do more than that, and try to restore values that were on the stack prior to save, etc? Frits van Bommel wrote: > > Nyx wrote: >> Hello, >> >> I would just like to ask if it's possible to explicitly free allocas. >> This >> is because I
2020 Apr 16
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
On Sat, Mar 28, 2020 at 2:20 PM Eli Friedman <efriedma at quicinc.com> wrote: > This would specifically be for cases where we try to rewrite the > signature? I would assume we should forbid rewriting the signature of a > call with an operand bundle. And once some optimization drops the bundle > and preallocated marking, to allow such rewriting, the signature doesn’t > need
2020 Mar 28
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
Sorry for the delay. Arthur Eubanks has started working on the design here: https://reviews.llvm.org/D74651 I felt I should follow up here about that. On Mon, Jan 27, 2020 at 6:47 PM Eli Friedman <efriedma at quicinc.com> wrote: > It doesn’t seem like multiple call sites should be a problem if they’re > sufficiently similar? If the argument layout for each callsite is the > same,
2013 Jul 29
0
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
Hi Reid, On 25/07/13 23:38, Reid Kleckner wrote: > Hi LLVM folks, > > To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able > to take the address of an outgoing call argument slot. This is > http://llvm.org/PR5064 . > > Problem > ------- > > On Windows, C structs are pushed right onto the stack in line with the other > arguments. In
2017 Jul 25
2
why is llvm.stacksave() necessary?
Hi all, the language reference for the alloca instruction states: The ‘alloca‘ instruction allocates memory on the stack frame of the currently executing function, to be automatically released when this function returns to its caller. when using come c code like void myfunc(void){ int i=4; double d[i]; } the ir shows enclosing llvm.stackSave & restore constructs, enclosing the alloca