search for: stackrestor

Displaying 20 results from an estimated 49 matches for "stackrestor".

Did you mean: stackrestore
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.s...
2012 Feb 03
0
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
...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...
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
...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...
2015 Nov 17
3
asan for allocas on powerpc64
...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...
2015 Nov 23
2
asan for allocas on powerpc64
.../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...
2013 Jul 25
4
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
...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'...
2009 Sep 30
1
[LLVMdev] stackrestore
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
2015 Nov 12
4
Fwd: asan for allocas on powerpc64
...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...
2015 May 11
2
[LLVMdev] Interaction of stacksave/restore and stack spills
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...
2013 Oct 22
1
[LLVMdev] Starting implementation of 'inalloca' parameter attribute for MS C++ ABI pass-by-value
...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...
2015 Nov 23
2
asan for allocas on powerpc64
...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): >>>>> >>>>>...
2018 May 11
0
best way to represent function call with new stack in LLVM IR?
...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
2013 Jul 30
0
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
...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...
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 handling the cleanup of the stack in normal control flow (e.g. always for a...
2013 Jul 29
0
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
...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...
2018 Apr 09
2
Issue with shrink wrapping
...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...
2018 May 11
1
best way to represent function call with new stack in LLVM IR?
...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)...
2011 Nov 02
1
[LLVMdev] [LLVMDev]: UNREACHABLE executed!
...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...
2020 Apr 16
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
...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>
2018 May 11
2
best way to represent function call with new stack in LLVM IR?
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