similar to: [LLVMdev] Instruction Scheduling

Hello, I'm working on the text of my Master's Thesis and I have some doubts: 1. What algorithm is used in Selection Instruction ? What is the input ? 2. Where is described how the variations of List Scheduling work, in -pre-RA-sched phase ? -pre-RA-sched - Instruction schedulers available (before register allocation): =source -

On Sep 17, 2013, at 11:04 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > 1. The SD schedulers significantly impact the spill counts and the execution times for many benchmarks, but the machine instruction (MI) scheduler in 3.3 has very limited impact on both spill counts and execution times. Is this because most of you work on MI did not make it into the 3.3 release?

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

Dear LLVMdev, I've noticed an unusual behavior of the LLVM x86 code generator (with default options) that results in nearly a 4x slow-down in floating-point throughput for my microbenchmark. I've written a compute-intensive microbenchmark to approach theoretical peak throughput of the target processor by issuing a large number of independent floating-point multiplies. The distance

On Thu, Feb 04, 2010 at 13:59:08 -0800, Evan Cheng wrote: > A more pressing need is a pre-regalloc scheduler that can switch modes to > balance reducing latency vs. reducing register pressure. Right. I'm actually working on implementing a variant of IPS (Goodman and Hsu, Code scheduling and register allocation in large basic blocks, http://doi.acm.org/10.1145/55364.55407) based on the

On Feb 5, 2010, at 2:01 AM, Gergö Barany wrote: > On Thu, Feb 04, 2010 at 13:59:08 -0800, Evan Cheng wrote: >> A more pressing need is a pre-regalloc scheduler that can switch modes to >> balance reducing latency vs. reducing register pressure. > > Right. I'm actually working on implementing a variant of IPS (Goodman and > Hsu, Code scheduling and register allocation

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, I am currently writing a paper documenting a research project that we have done on pre-allocation instruction scheduling to balance ILP and register pressure. In the paper we compare the pre-allocation scheduler that we have developed to LLVM's default schedulers for two targets: x86-64 and x86-32. We would like to include in our paper some brief descriptions of the two LLVM

On Sep 29, 2012, at 2:43 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > Hi, > > We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark

I'm looking over the RR list scheduler and am wondering about how the Sethi-Ullman numbers are used. The comments and the code indicate that the node with the lowest S-I number is scheduled first. Traditionally S-I scheduling schedules the node with the highest S-I number first. What am I missing? -Dave

On Sep 17, 2011, at 10:07 AM, Ghassan Shobaki wrote: > Hi, > > I am currently writing a paper documenting a research project that we have done on pre-allocation instruction scheduling to balance ILP and register pressure. In the paper we compare the pre-allocation scheduler that we have developed to LLVM's default schedulers for two targets: x86-64 and x86-32. We would like to

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%

On Sep 23, 2011, at 6:16 AM, Ghassan Shobaki wrote: > 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

A more pressing need is a pre-regalloc scheduler that can switch modes to balance reducing latency vs. reducing register pressure. The problem is the current approach is the scheduler is locked into one mode or the other. For x86, it generally makes sense to schedule for low register pressure. That is, until you are dealing with a block that are explicitly SSE code in 64-bit mode. In that case,

Hi, We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark tests that compare our algorithm with LLVM's pre-allocation scheduling algorithm. First, here is a

Hi Andy, Please see my in-line answers below. Regards -Ghassan ________________________________ From: Andrew Trick <atrick at apple.com> To: Ghassan Shobaki <ghassan_shobaki at yahoo.com> Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> Sent: Friday, September 23, 2011 8:02 PM Subject: Re: [LLVMdev] Pre-Allocation Schedulers in LLVM On Sep 23, 2011, at

On 17 September 2013 19:04, Ghassan Shobaki <ghassan_shobaki at yahoo.com>wrote: > 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. > Hi Ghassan, This is an

Hello, On Fri, Nov 14, 2008 at 6:57 PM, H. Johnson <misc at faradayco.com> wrote: > llc -march=x86 tempfileB.bc yields: > llc: for the -march option: : Cannot find option named 'x86'! Run llc -help and see, if any backends were linked in. It will show you list of all backends, which were 'registered' and thus known to llc. -- With best regards, Anton Korobeynikov

Sandeep Patel wrote: > My goal is to have Cortex-A9 support complete in far less than three > months. I've recently gotten some additional help toward that goal, so > the pace should pick up soon. > > As far as compiler texts, there are many newer texts to recommend as > just about all the major optimization passes are done differently > after SSA-form appeared in about

Hi all. I'm looking for an advice on how to deal with inefficient code generation for Intel Nehalem/Westmere architecture on 64-bit platform for the attached test.cpp (LLVM IR is in test.cpp.ll). The inner loop has 11 iterations and eventually unrolled. Test.lea.s is the assembly code of the outer loop. It simply has 11 loads, 11 FP add, 11 FP mull, 1 FP store and lea+mov for index