similar to: [LLVMdev] Shrink Wrapping - RFC and initial implementation

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

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

On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > 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

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

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

On 2017-10-30 21:20, Hal Finkel wrote: > On 10/30/2017 12:20 PM, junbuml at codeaurora.org wrote: >> On 2017-10-27 19:50, Hal Finkel wrote: >>> On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: >>> >>>> When compiling C code below for AArach64, I saw that shrink-wrapping >>>> didn't happen due to the very early uses of CSRs in the entry

On 2017-11-10 07:47, Nemanja Ivanovic wrote: > One thing I thought about doing a while back and never really wrote a > POC for is the following: > - Make FirstCSRCost a property of the MachineBasicBlock (or create a > map of MBB* -> FirstCSRCost) > > - Implement a pre-RA pass that will populate the map as follows: > > - Identify all blocks with calls > > -

On 2017-11-14 17:22, Quentin Colombet wrote: > Hi, > > I think it is kind of artificial to tie the CSRCost with the presence > of calls. > I think I’ve already mentioned it in one of the review, but I > believe it would be better to differentiate when we want to use a CSR > to avoid spilling or to avoid splitting. CSR instead of spilling is > good, CSR instead of

On 2017-11-17 13:10, Quentin Colombet wrote: >> On Nov 16, 2017, at 2:31 PM, junbuml at codeaurora.org wrote: >> On 2017-11-14 17:22, Quentin Colombet wrote: >> >>> Hi, >>> I think it is kind of artificial to tie the CSRCost with the >>> presence >>> of calls. >>> I think I’ve already mentioned it in one of the review, but I

When compiling C code below for AArach64, I saw that shrink-wrapping didn't happen due to the very early uses of CSRs in the entry block. So CSR spills/reloads are executed even when the early exit block is taken. int getI(int i); int foo(int *P, int i) { if (i>0) return P[i]; i = getI(i); return P[i]; } It's not that hard to find such cases where

On 2017-10-27 19:50, Hal Finkel wrote: > On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: > >> When compiling C code below for AArach64, I saw that shrink-wrapping >> didn't happen due to the very early uses of CSRs in the entry block. >> So CSR spills/reloads are executed even when the early exit block is >> taken. >> >> int getI(int i); >>

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

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 have an issue that I've been wrestling with for quite some time and I'm hoping that someone with a deeper understanding of the register allocator can help me with. Namely, I am trying to teach RA to split a live range rather than allocating a CSR. I've attempted a very large number of tweaks to the costs (both existing and experimental ones that I've added). However, despite all

Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2.

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

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

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. > I am putting this information > into my temp. wiki page in hopes of getting it into the dev wiki when > that is available. The dev wiki is up at its temporary name http://google2.osuosl.org/wiki/. Feel free to dump your stuff on there. On Fri, Mar 13, 2009 at 7:43 PM, John Mosby <ojomojo at gmail.com> wrote: > Hi Evan, > Thanks very much for the review, I am