similar to: Spill Weight In InlineSpiller

Hi Quentin, Thanks for the reply! However, we are not using any profiling-based compilation in our current work. We are assuming that, if PGO is disabled, the register allocator (and any other pass that needs basic block frequency info) will be basing its decisions on some kind of *static" basic block frequency info that are based on some compile-time heuristics and at least capture loop

On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-15 16:39 , Benjamin Kramer wrote: >> Do you want to take over this effort or should I poke more at it? > > Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. OK, will do. Jakob any comments on the

On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > >> On 2013-06-15 16:39 , Benjamin Kramer wrote: >>> Do you want to take over this effort or should I poke more at it? >> >> Since you've already started, it's easier if you poke more at

[Splitting this out from the original thread to reduce noise in it] On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even

Thank you for the answers! We are currently trying to test the MI scheduler. We are using LLVM 3.3 with Dragon Egg 3.3 on an x86-64 machine. So far, we have run one SPEC CPU2006 test with the MI scheduler enabled using the option -fplugin-arg-dragonegg-llvm-option='-enable-misched:true' with -O3. This enables the machine scheduler in addition to the SD scheduler. We have verified this by

On 17.09.2013, at 20:04, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > Hi Andy, > > We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. > > Here are our

Hi Andy, We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. Here are our main findings: 1. The SD schedulers significantly impact the spill counts and the execution times for many

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

Thank you for the answers, Jakob! That's really informative for someone who is still new to LLVM like me. Please see my responses below. -Ghassan  ________________________________ From: Jakob Stoklund Olesen <stoklund at 2pi.dk> To: Ghassan Shobaki <ghassan_shobaki at yahoo.com> Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> Sent: Tuesday, August 16,

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

Preallocation Instruction Scheduling with Register Pressure Minimization Using a Combinatorial Optimization Approach G. Shobaki, M. Shawabkeh and N. Abu-Rmaileh ACM Transactions on Architecture and Code Optimization (TACO). vol. 10, issue 3, Article 14 (Sept. 2013) http://dx.doi.org/10.1145/2512432 Regards Ghassan Shobaki, PH.D Assistant Professor Department of Computer Science Princess Sumaya

/// Optimizations after all the reg selections and spills are done. void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); } Seems a problematic function to me, as hoistAllSpills() uses TII.storeRegToStackSlot() to insert new spills. The problem is, TII.storeRegToStackSlot is allowed to create new virtual registers, which can not be allocated a range as this whole thing is called

I have been doing some benchmarking on x86 using llvm 2.9 with the llvm-gcc 4.2 front end. I noticed that the -march and -mtune options make a significant positive difference in x86-32 mode but hardly make any difference in x86-64 mode. The small difference that I am measuring when the target is x86-64 could easily be random variation, while for the x86-32 target I am measuring a huge difference

Hi, We are currently in the process of upgrading from LLVM 2.9 to LLVM 3.3. We are working on instruction scheduling (mainly for register pressure reduction). I have been following the llvmdev mailing list and have learned that a machine instruction (MI) scheduler has been implemented to replace (or work with?) the selection DAG (SD) scheduler. However, I could not find any document that

On Aug 15, 2011, at 1:27 AM, Ghassan Shobaki wrote: > One factor that is causing our current register pressure estimate to be off is not being able to properly account for live-in and live-out registers (both virtual and physical). As far as we can tell, LLVM represents live-in regs with CopyFromReg instrs and live-out regs with CopyToReg instrs. However, it looks that in a given basic block,

Hi, We are working on a research project whose objective is developing a pre-allocation scheduling algorithm that achieves the optimal balance between exploiting ILP (hiding latencies) and minimizing register pressure.  A prototype of our algorithm has been implemented and integrated into an experimental version of LLVM 2.9. Our algorithm is based on a combinatorial optimization approach, which

Hi Renato, Please see my answers below. Thanks -Ghassan ________________________________ From: Renato Golin <renato.golin at linaro.org> To: Ghassan Shobaki <ghassan_shobaki at yahoo.com> Cc: Andrew Trick <atrick at apple.com>; "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> Sent: Thursday, September 19, 2013 5:30 PM Subject: Re: [LLVMdev] Experimental

Hi Andrew, What we have is not a patch to any of LLVM's schedulers. We have implemented our own scheduler and integrated it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for most common x86 instructions to our scheduler and noticed a 10%