search for: stackrestor

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.s...

...oves an alloca instruction out of the loop, to the new loop header. 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 th...

...er. 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 &g...

...gt; Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for > powerpc64. I've had a look at why it doesn't work. I think the only > problem is in the call to __asan_allocas_unpoison that is inserted at > the end of the "for" loop (just before a stackrestore instruction). > > The call function is created something like this (paraphrasing from > lib/Transfoms/Instrumentation/AddressSanitizer.cpp): > > // call __asan_allocas_unpoison(uptr top, uptr bottom); > // NB "top" here means lowest address and &quot...

.../TestCases/alloca_vla_interact.cc is XFAILed for >>> powerpc64. I've had a look at why it doesn't work. I think the only >>> problem is in the call to __asan_allocas_unpoison that is inserted at >>> the end of the "for" loop (just before a stackrestore instruction). >>> >>> The call function is created something like this (paraphrasing from >>> lib/Transfoms/Instrumentation/AddressSanitizer.cpp): >>> >>> // call __asan_allocas_unpoison(uptr top, uptr bottom); >>> // NB...

...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 selection dag. LLVM can also apply this to dynamic allocas from inline functions to ensure that optimizers don'...

Hi, is there a convenient way to get all allocations popped from the stack by llvm.stackrestore? Is this even decidable at compile time? Thanks Marc

...rrect mailing list address.) Hi, Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for powerpc64. I've had a look at why it doesn't work. I think the only problem is in the call to __asan_allocas_unpoison that is inserted at the end of the "for" loop (just before a stackrestore instruction). The call function is created something like this (paraphrasing from lib/Transfoms/Instrumentation/AddressSanitizer.cpp): // call __asan_allocas_unpoison(uptr top, uptr bottom); // NB "top" here means lowest address and "bottom" means highest! IRB.CreateCa...

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 -------------- next...

...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 (cdecl). The backend will be responsible for restoring the stack pointer on both return and exception edges. On Thu, Jul 25, 2013 at 2:38 PM, Reid Kleckner <rnk at google.com> wrote: > Hi LLVM folks, &gt...

...gt; powerpc64. I've had a look at why it doesn't work. I think the >>>>> only >>>>> problem is in the call to __asan_allocas_unpoison that is >>>>> inserted at >>>>> the end of the "for" loop (just before a stackrestore >>>>> instruction). >>>>> >>>>> The call function is created something like this (paraphrasing >>>>> from >>>>> lib/Transfoms/Instrumentation/AddressSanitizer.cpp): >>>>> >>>>>...

...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 more). -- whitequark

...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 selection dag. > > LLVM can also apply this to dynamic allocas from inline functions to e...

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 handling the cleanup of the stack in normal control flow (e.g. always for a...

...le 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 selection dag. > > LLVM can also apply this to dynamic allocas from inline functions to ensure that...

...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 certain path, the call...

...le-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 more)...

...i64* %99 %101 = sub i64 %100, 1 store i64 %101, i64* %99 %102 = bitcast %0* %13 to [8 x i8]* %103 = getelementptr %1* %54, i64 0, i32 0, i32 8 %104 = bitcast i8* %103 to [8 x i8]* %105 = load [8 x i8]* %102 store [8 x i8] %105, [8 x i8]* %104 call void @p1(%1* %54) call void @llvm.stackrestore(i8* %53) %106 = load %0** %31 %107 = ptrtoint %0* %106 to i64 %108 = icmp ne i64 %107, 0 br i1 %108, label %111, label %117 ; <label>:109 ; preds = %83 %110 = bitcast %0* %80 to i8* call void @destroy(i8* inttoptr (i64 161025200 to i8*), i8* i...

...I’m happy to pick whatever rule is > easiest for us. I’m more concerned with ensuring nothing blows up if we > inline a call to a function that contains a VLA, or something like that. > Sounds good. Inlining dynamic allocas and VLAs should already just work. The inliner places stacksave/stackrestore calls around the original call site, if dynamic allocas were present in the inlined code. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200416/21452d2a/attachment.html>

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