similar to: [LLVMdev] Issues with the llvm.stackrestore intrinsic

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

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

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

Hi everyone, I'm curious about the constraints that come with the usage of llvm.stacksave/llvm.stackrestore. Specifically I was wondering what the contract of their usage was with respect to SSA variables defined after llvm.stacksave. It seems to me that they could get spilled to a stack slot, which I'm concerned stackrestore might mess up. Is this a valid concern? Thanks, Keno

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

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

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

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

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

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

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.

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

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

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

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. If this is not possible, an alternate solution would be for me to allocate an array of bytes larger than all the struct types I may be using, and cast that

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

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

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

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. Recursive calls can have a runtime-decided stack usage, and therefore I am adding a frontend feature that will heap-allocate memory to use for some function calls. The idea is that recursion adds cycles to the call graph, and we know at

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,