similar to: [LLVMdev] Experimental Evaluation of the Schedulers in LLVM 3.3

On 26 September 2013 08:30, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > So, when the MI scheduler is enabled, will SD scheduling be totally disabled > or the SD scheduler will be automatically set to do source scheduling? The latter. The SD scheduler is where the DAG is converted into the linear MachineInstr representation. Some kind of scheduling *has* to happen. Tim.

Hi Andy, Are there plans to change the default scheduler for ARM targets in 3.4? -Slava -- View this message in context: http://llvm.1065342.n5.nabble.com/MI-Scheduler-vs-SD-Scheduler-tp58975p61607.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

So, when the MI scheduler is enabled, will SD scheduling be totally disabled or the SD scheduler will be automatically set to do source scheduling? -Ghassan ________________________________ From: Andrew Trick <atrick at apple.com> To: llvmdev at cs.uiuc.edu Cc: Ghassan Shobaki <ghassan_shobaki at yahoo.com> Sent: Thursday, September 26, 2013 9:24 AM Subject: Re: [LLVMdev]

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

On Oct 8, 2013, at 2:05 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > On 05.10.2013, at 08:01, Andrew Trick <atrick at apple.com> wrote: > >> >> On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com> wrote: >> >>> >>> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at google.com> wrote: >>>

On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at apple.com> wrote: > This week, I'll see if we can enable MI scheduling by default for x86. I'm not sure which flags you're using to test it now. But by making it default and enabling the corresponding coalescer changes, we

I should note here that although SPEC provided us with a sufficiently large sample for our spill-count experiment, I don't think that SPEC has enough hot functions with spills to make our execution-time results statistically significant. That's because SPEC has many benchmarks with peaky profiles, where one of two functions dominate the execution time. So, if one heuristic gets very

Our test machine has two Intel Xeon E5540 processors running at 2.53 GHz with 24 GB of memory. Each CPU has 8 threads (16 threads in total). All our tests, however, were single threaded. Which result is particularly surprising for you? The low impact of the MI scheduler, the relatively good performance of the source scheduler or the relatively poor performance of the ILP scheduler? Thanks

On 05.10.2013, at 08:01, Andrew Trick <atrick at apple.com> wrote: > > On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at google.com> wrote: >> >>> >>> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at apple.com> wrote:

In my last message, I explained the goals of the generic MI scheduler and current status. This week, I'll see if we can enable MI scheduling by default for x86. I'm not sure which flags you're using to test it now. But by making it default and enabling the corresponding coalescer changes, we can be confident that benchmarking efforts are improving on the same baseline. At that point, I

On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at apple.com> wrote: >> This week, I'll see if we can enable MI scheduling by default for x86. I'm not sure which flags

On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at apple.com> wrote: > This week, I'll see if we can enable MI scheduling by default for x86. I'm > not sure which flags you're using to test it now. But by making it default > and enabling the corresponding coalescer changes, we can be confident that > benchmarking efforts are improving on the same baseline.

On 19 September 2013 17:25, Ghassan Shobaki <ghassan_shobaki at yahoo.com>wrote: > Ghassan: You have made me so curious to try other benchmarks in our future > work. Most academic publications on CPU performance though use SPEC. You > can even find some recent publications that are still using SPEC CPU2000! > When I was at AMD in 2009, performance optimization and benchmarking

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

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

Hi, Thanks for your explanations! How is the big picture for supporting in-order VLIW architectures and the like though? I am asking because I am currently implementing instruction scheduling in our own backend for our custom Patmos processor, for which I need to support both branch delay slots and bundles, some restrictions regarding bundles. For the moment, I am quite happy with a simple

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

Previously I had asked how to write then read back IR to/from a file. The write code looked like: LLVMContext ctx; SMDiagnostic diag; Module *m = ParseIRFile( "my_file", diag, ctx ); However, the code I'm trying to retrofit LLVM IR into passes me just a std::ostream&. How can I read IR from a std::ostream? I figured out how to use raw_os_ostream to adapt a

Hey all - does RHES4/CentOS4 beta contain a recent integration of Subversion? I've been holding off trying to retro-fit CentOS 3.x on our CVS server, hoping that the official channels aready had it in store for the future. Not that you *can't* retrofit, I was just uncomfortable upgrading so many stock packages. Anyone have it installed, can take a look for me? thx, -te -- Troy