similar to: [LLVMdev] Shrink Wrap for ARM architecture?

I know nothing about this pass, but here are a few comments. > Does anyone know if the shrink wrap pass works for ARM architecture? First, how are you invoking it? Looks to be a command line option, so -mllvm -shrink-wrap should enable it. Assuming you have a Debug build, you can see the debug output using -debug-only=shrink-wrap. > I tried it seems not working. Which architecture

The current implementation in LLVM is experimental at best. It probably should be ripped out. Evan On Oct 30, 2013, at 2:10 PM, mcrosier at codeaurora.org wrote: > I know nothing about this pass, but here are a few comments. > >> Does anyone know if the shrink wrap pass works for ARM architecture? > > First, how are you invoking it? > > Looks to be a command line

On 30 October 2013 22:34, Rafael Espíndola <rafael.espindola at gmail.com>wrote: > On 30 October 2013 20:08, Evan Cheng <evan.cheng at apple.com> wrote: > > The current implementation in LLVM is experimental at best. It probably > should be ripped out. > > Patch attached :-) > Thanks Rafael! It's a shame to see a feature go away that easily, but I also

On 30 October 2013 20:08, Evan Cheng <evan.cheng at apple.com> wrote: > The current implementation in LLVM is experimental at best. It probably should be ripped out. Patch attached :-) Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: t.patch Type: text/x-patch Size: 57169 bytes Desc: not available URL:

LGTM. Was that the last use of SparseBitVector? Thanks, /jakob > On 30 Oct 2013, at 22:34, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> On 30 October 2013 20:08, Evan Cheng <evan.cheng at apple.com> wrote: >> The current implementation in LLVM is experimental at best. It probably should be ripped out. > > Patch attached :-) > >

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

On Thu, Nov 7, 2013 at 11:02 AM, Yin Ma <yinma at codeaurora.org> wrote: > Hi John, > > > > It seems the dereferencing a NULL pointer is undefined behavior but > > Calling a function through a null pointer seems o.k. > What is the well defined behavior of calling a null function pointer? > > > If so , for this place, we need comment out the check. >

On 24 May 2013 17:39, Chad Rosier <mcrosier at apple.com> wrote: > One side effect of dynamically computing the aliases is that the iterator > does not guarantee that the entries are ordered or that duplicates have > been removed. > Hi Chad, Sounds like you're growing the list (thus the lookup time), rather than shrinking, as I take it was Jacob's original intention?

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?

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,

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

I just want to know ,how can I developing a LLVM Pass on Windows' visual studio? I can develop a Pass on linux,but I can't do it on windows. 2013/3/15 <llvmdev-request at cs.uiuc.edu> > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit >

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

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

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

Hi all, We've seen several examples recently of performance opportunities on POWER if we can improve the location of save/restore code for callee-saved registers. Both Nemanja and myself have discussed this with several people, and it seems that there are two possibilities for improving this: 1. Extend shrink wrapping to make the analysis of callee-saved registers more precise. 2.

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

Thanks alot Chad for quick response. Does this means that, we can not use LLVM optimizations except O1, O2, O3, O4 and unroll-loops with clang? One more thing I would like to know that If I want to process multiple modules with opt at the same time like opt -adce *.bc then how is it possible with opt in one go, if I process all the bytecode files within Makefile. Thanks. Shahzad On Thu, Jun