similar to: Issue with shrink wrapping

Displaying 20 results from an estimated 800 matches similar to: "Issue with shrink wrapping"

2018 Apr 10
0
Issue with shrink wrapping
Hello Momchil, (CC’ing more people that could correct me if I’m wrong) Thanks for looking into this. More answers below: > On 9 Apr 2018, at 17:57, Momchil Velikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > So, I have this testcase: > > void f(int n, int x[]) { > if (n < 0) > return; > > int a[n]; >
2009 Mar 05
0
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Here is an updated patch for shrink wrapping with: - spills/restores done with stack slot stores/loads - stack adjustment removed - refactoring (but still in need of more) - spill/restore insertion code unified with spill/restore placement code Documentation available here<http://wiki.github.com/jdmdj/llvm-work/shrink-wrapping-work> illustrates shrink wrapping with loops and discusses a
2015 Nov 20
2
[AArch64] bug in shrink-wrapping
Hi Quentin, After shrink-wrapping was enabled as default on AArch64, llc has a seg fault when compiling the attached .ll file on AArch64. My command is llc -mcpu=cortex-a57 bug.ll Best, Haicheng -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.ll Type: application/octet-stream Size: 8983 bytes Desc: not available URL:
2009 Mar 03
2
[LLVMdev] Shrink Wrapping - RFC and initial implementation
On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote: > > On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > > Obviously, all of this applies only when spills are done with push/pop, > which is the case on x86. I used this issue to start looking at generalizing > how spills and restores are handled, before looking too closely at other > targets, and
2015 Nov 20
2
[AArch64] bug in shrink-wrapping
Hi Arnaud, Thanks for following up with that and sorry for the breakage. Couple of comments: MachineLoopInfo *MLI; + RegScavenger *RS; Would it make sense to use a unique_ptr here? That should eliminate the need of having explicit deletes. +; RUN: llc -mtriple=aarch64-linux-gnu -o - %s Add -enable-shrink-wrap=true and a second RUN line with -enable-shrink-wrap=false. Then add check lines
2019 Apr 15
2
Loop Strength Reduction Pass Does Not Work for Some Varialbles Related to Induction Variables
Dear Momchil, Thanks a lot for your prompt reply and kindly suggestion. The code will truly lead to some automatic unrolling with GCC and increase the number of operations in the assembly code. However, I am focus on the the IR optimization and the calculation of the array element offest, which may need multiplication if the IR instruction GEP is lowered to arithmetic operations. The
2009 Mar 12
4
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Hi John, It looks pretty good. Thanks for working on this. Some comments: 1. Some of the functions that you introduced, e.g. stringifyCSRegSet probably ought to be "static" and ifdef'ed out when NDEBUG is defined. 2. + // DEBUG + if (! MBB->empty() && ! CSRUsed[MBB].intersects(restore)) { + MachineInstr* MI = BeforeI; + DOUT <<
2019 Apr 15
2
Loop Strength Reduction Pass Does Not Work for Some Varialbles Related to Induction Variables
Dear all, Hi! Recently, I try to combine the passes SeparateConstOffsetFromGEP and LoopStrengthReduction to transform the multiplication in the lowered GEP IRs into addition. However, it seems LoopStrengthReduction is unable to remove all the multiplications for the element offset calculation. My test code is shown below and thanks a lot in advance for your time and suggestion!
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
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
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
2009 Mar 13
0
[LLVMdev] Shrink Wrapping - RFC and initial implementation
Hi Evan, Thanks very much for the review, I am implementing your suggestions today and will have the next patch together this weekend. A few questions/comments: On Thu, Mar 12, 2009 at 10:05 AM, Evan Cheng <echeng at apple.com> wrote: > > 1. Some of the functions that you introduced, e.g. stringifyCSRegSet > probably ought to be "static" and ifdef'ed out when NDEBUG
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
2020 Jun 16
3
Codifying our Brace rules-
My 2 pennies is braces add unnecessary clutter and impair readability when used on a *single-line* statement. I count comments, that are on their own line as statement(s). For example: BAD: if (cond) // Comment foo(); GOOD: if (cond) { // Comment foo(); } BAD: if (cond) { foo(); // Comment } GOOD: if (cond) foo(); // Comment BAD: if (cond) for(;;) foo() GOOD: if (cond)
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
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
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
2020 Jan 21
4
aarch64 does not emit DW_AT_Location
Hi Devs, debug info emitted by llvm does not contain DW_AT_Location for Formal parameter if it is an aggregate like below case 1) aggregate contain more than 4 homogeneous and size more than 128 bits i.e. typedef struct{ int a,b,c,d,e; }mystruct; void foo(mystruct ms){ } 2) aggregate contain hetrogeneous type and size more than 128 bits. i.e. typedef struct{ int a,b; float c,d,e; }mystruct; void