search for: stacksave

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, 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 with tmp4] call llvm.stackrestore(tmp3) Then some transformation rewrites this to tmp1 = call llvm.stacksave() tmp2 =...

...he 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 related to 'd'. thellvm.stacksafe reference explains: This intrinsic is used to remember the current state of the function stack... In practice, this pops any alloca blocks from the stack that were allocated after the llvm.stacksave was execut...

...Shouldn't we also check on !isa<AllocaInst>(Inst) before allowing to move it? The code that breaks because of the moved alloca looks like start: [...] br loopstart loopbody: [use alloc'd mem] call stackrestore(%oldsp) br loopstart loopstart: %oldsp = call stacksave() alloca [...] brcond loopbody, end end: [use alloc'd mem] call stackrestore(%oldsp) Then LoopRotation clones the stacksave from bb3 to bb1 and _moves_ the alloca from bb3 to bb1. So the alloca is moved outside the loop instead of having it execute each lap. But there still is...

...lee cleanup (thiscall), but free functions are caller cleanup (cdecl). Features -------- A few weeks ago, I sat down with some folks at Google and we came up with this proposal, which tries to add the minimum set of LLVM IL features to make this possible. 1. Allow alloca instructions to use llvm.stacksave values to indicate scoping. This creates an SSA dependence between the alloca instruction and the stackrestore instruction that prevents optimizers from accidentally reordering them in ways that don't verify. llvm.stacksave in this case is taking on a role similar to CALLSEQ_START in the sele...

...lvm-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 to pass a value returned by stacksave to stackrestore. If you need more control, consider @llvm.read_register and @llvm.write_register intrinsics, which allow arbitrary manipulation of the stack pointer (but, I think, will inhibit optimizations mor...

...get a stack > trace? Actually, it looks to me like it generates bad code. $ llvm-dis < out.bc | grep -- -3 %tmp4.i.i = getelementptr int (...)** %tmp.i.i, int -3 [and a bunch more, one of which is in main()...] $ llc -march=c -o=cbe.c out.bc WARNING: this target does not support the llvm.stacksave intrinsic. $ gcc -g cbe.c [n.b.: compiles successfully!] $ gdb a.out (gdb) run Starting program: a.out Program received signal SIGSEGV, Segmentation fault. 0x08048958 in main () at cbe.c:1154 1154 ltmp_173_15 = *((int *)(&ltmp_172_54[-3])); (gdb) print ltmp_172_54 $1 = (int (**)()) 0x0...

...mpile to C: llvm-link should work fine because its just dealing with bytecode. BTW, You could put all the std/*.o and sup/*.o files into a bc archive using llvm-ar and then just link with that archive. > > $ llc -o=cbe.c -march=c linked.o > WARNING: this target does not support the llvm.stacksave intrinsic. > $ gcc cbe.c > /var/tmp//ccVAM4W2.o(.text+0x329a): In function `operator new(unsigned int)': > : undefined reference to `__cxa_throw' > [...and more errors] > $ > > But __cxa_throw is right there, in sup/eh_throw.o, and in linked.o, it > just isn't b...

...li out.bc Segmentation fault (core dumped) $ Oops, no go. Try a different way: $ llvm-g++ -emit-llvm -c x.cpp $ llvm-link -o=linked.o x.o std/*.o sup/*.o $ lli linked.o hello world $ So far, so good! Compile to C: $ llc -o=cbe.c -march=c linked.o WARNING: this target does not support the llvm.stacksave intrinsic. $ gcc cbe.c /var/tmp//ccVAM4W2.o(.text+0x329a): In function `operator new(unsigned int)': : undefined reference to `__cxa_throw' [...and more errors] $ But __cxa_throw is right there, in sup/eh_throw.o, and in linked.o, it just isn't being emitted as C code. (at this point,...

> Clang does this because clang intentionally generates IR naïvely and relies on LLVM optimisation passes to clean it up. > > In the case of C VLAs, the size of the alloca changes whenever the declaration goes into scope. By emitting a stack save and restore for d, clang doesn’t need to have different IR generating code for your example and for this one: > > void myfunc(void >

> In C, the ‘minimal’ part is called the ‘scope’. Variables are always destroyed in the inverse order to the order in which they are created and so it’s always trivial to translate each into a stack save followed by an alloca when the variable comes into scope and a stack restore when the variable goes out of scope. > >> what would happen if stack safe/remove would be neglected?

...; before allowing to move it? > > > The code that breaks because of the moved alloca looks like > > start: >   [...] >   br loopstart > > loopbody: >   [use alloc'd mem] >   call stackrestore(%oldsp) >   br loopstart > > loopstart: >    %oldsp = call stacksave() >   alloca >   [...] >   brcond loopbody, end > > end: >   [use alloc'd mem] >   call stackrestore(%oldsp) > > Then LoopRotation clones the stacksave from bb3 to bb1 and _moves_ the > alloca from bb3 to bb1. So the alloca is moved outside the loop instead > of...

...] = 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. The testcase allocates a VLA, thus clang generates calls to `llvm.stacksave` and `llvm.stackrestore`. The latter call is lowered to `mov sp, x2`, however this move does not affect decisions made by the shrink wrapping pass, as the instruction does not use or define a callee-saved register. The end effect is that placement of register save/restore code is such that along a...

...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 free all allocas performed after calling the stacksave intrinsic. http://llvm.org/docs/LangRef.html#int_stacksave

...nd, 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 to pass a value returned by stacksave to stackrestore. > If you need more control, consider @llvm.read_register and > @llvm.write_register intrinsics, which allow arbitrary manipulation > of the stack pointer (but, I think, will inhib...

...;, 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 clarify that it is illegal for an optimization to raise an alloca used as an inalloca argument across a stacksave, and fix any transforms that do this. In particular, I'll look at the inliner, which is the most likely to move allocas. Furthermore, any call that uses an inalloca argument must have an associated stackrestore field, regardless of whether it's callee cleanup (thiscall) or caller cleanup...

...r cleanup (cdecl). > > Features > -------- > > A few weeks ago, I sat down with some folks at Google and we came up with > this > proposal, which tries to add the minimum set of LLVM IL features to make > this > possible. > > 1. Allow alloca instructions to use llvm.stacksave values to indicate > scoping. > > This creates an SSA dependence between the alloca instruction and the > stackrestore instruction that prevents optimizers from accidentally > reordering > them in ways that don't verify. llvm.stacksave in this case is taking on a > role &g...

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 @llvm.memset.p0i8.i64(i8* %8, i8 0, i64 %7, i32 0, i1 false) %9 = bitcast %1* %0 to [8 x i8]* %10 = bitcast %0* %3 to...

...egion. We could write an algorithm for > assigning regions to each block. The region is implicit in the IR. These > are the things that could create regions: > > - call.preallocated.setup > > - catchpad > > - cleanuppad > > - lifetime.start? unclear > > > > stacksave/stackrestore. > > > > I don’t think there’s any reason to make lifetime intrinsics properly > nest; nothing really cares, as far as I know. (The current lifetime > intrinsics have problems, but I don’t think that’s one of them.) > > > > Passes are required to ensure t...

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