similar to: RFC: Shrink wrapping vs SplitCSR

Hello Quentin, I see your work on shrink-wrapping optimization at http://reviews.llvm.org/rL236507 IPRA has benefited shrink-wrapping optimization ( I have noticed that on sqlite3 test-case) so I did read Fred Chow's paper and compare that approach with yours I did not understand much of your work :-( in comparison to original paper but I feel that current approach is not generating same

On Wed, Jun 29, 2016 at 1:43 AM, vivek pandya via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Quentin, > > I see your work on shrink-wrapping optimization at > http://reviews.llvm.org/rL236507 > IPRA has benefited shrink-wrapping optimization ( I have noticed that on > sqlite3 test-case) so I did read Fred Chow's paper and compare that > approach with

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:

Hi, Sorry for bringing back such an old thread. I am interested in the latest status of the shrink wrapping pass in LLVM. I have found some active work back in 2017 from Francis Visoiu Mistrih and Kit Barton from the following links. However, it seems that all the work suddenly stops and the improvement for the existing shrink wrapping did not make it into the trunk. Is this work abandoned?

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

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

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

Hi Francis, Thanks for getting back to me. Could you please provide more details about the problems you encounter with those tools and what improvements required to improve compact unwinding format? Most of my experience is in the mid end, but it is still surprising to me that an improved shrink wrap will break that many tools, considering the fact that gcc has a good shrink wrapping pass and

On Mar 13, 2009, at 10:43 AM, John Mosby wrote: > > I started to reduce the traversals, then decided to work on edge > splitting because I believe it may be needed to finish shrink > wrapping. Hmm. I don't think edge splitting would be required for correctness, right? There is always a common predecessor / successor. For the first pass, we should not be shooting to

Hi, Shrink-wrapping capabilities, i.e., better placement of prologue and epilogue sequences, landed in r236507 but are not yet enabled by default. Since r236507 AArch64 is shrink-wrapping ready, meaning we can turn the pass on for this target. I’ve done the same for X86 in r 238293. Now, I need your help to test and benchmark how shrink-wrapping perform on those targets. The goal is to decide

Here is the latest shrink wrapping patch, with fixes for issues identified by Evan. I am including a few small additions/fixes to include/llvm/ADT/{SparseBitVector,DepthFirstIterator}.h. Files: include/llvm/ADT/DepthFirstIterator.h include/llvm/ADT/SparseBitVector.h lib/CodeGen/PrologEpilogInserter.cpp Evan, let me know how it looks when you get a chance. Thanks much, John >

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.

On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > Hello LLVMdev, > > I have been working with LLVM for just over a year now, mainly in > the area of compilation for HDLs like SystemVerilog and SystemC. > Most of this work dealt with translation to LLVM IR, representing > concurrent languages with LLVM and using LLVM analyses and transforms > for compiling onto proprietary

Hi Anton, Thanks for your questions, that's what I'm looking for. On Thu, Feb 26, 2009 at 5:33 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello, John > > > My limited implementation uses a workaround that adjusts the > > generation of prologue code and the frame indices used by > > the target eliminateFrameIndex() when necessary. I am

Hello LLVMdev, I have been working with LLVM for just over a year now, mainly in the area of compilation for HDLs like SystemVerilog and SystemC. Most of this work dealt with translation to LLVM IR, representing concurrent languages with LLVM and using LLVM analyses and transforms for compiling onto proprietary simulation acceleration hardware. All of this work used the C back end exclusively,

First, thanks very much for your comments! On Sat, Feb 28, 2009 at 8:05 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > > It is limited to X86 presently since that is the only target I have > > access to at the moment. > > What part of this is target dependent? Is this due to emitPrologue / > emitEpilogue being

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

Hello, John > My limited implementation uses a workaround that adjusts the > generation of prologue code and the frame indices used by > the target eliminateFrameIndex() when necessary. I am looking at > several approaches, but I would like input from anyone who > has an opinion. I haven't looked into the patch deep enough yet, but I have at least 2 questions: 1. How do all the

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

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]; >