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