similar to: [LLVMdev] Decimal Floating Point

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,

aparna kotha wrote: > Hi all: > > I need an instruction that can convert decimal values into floating > point numbers. > > i.e. say I have a decimal number 1110794174 (== 42355FBE in hex ) and > (== 45.3435 as a float) > > essentially the mantissa and exponent representation needs to be used. > > > Is there any way of doing this in llvm? I think

Hi all: I need an instruction that can convert decimal values into floating point numbers. i.e. say I have a decimal number 1110794174 (== 42355FBE in hex ) and (== 45.3435 as a float) essentially the mantissa and exponent representation needs to be used. Is there any way of doing this in llvm? Thanks and Regards -- -- Aparna Kotha Graduate Student Electrical and Computer Engineering

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

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

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

Thank you for the link! It is not clear though what -Oe actually implements. Does it simply optimize for speed as suggested by Chris or it does other things? Generally speaking, speed correlates well with low energy, because completing the task in fewer cycles means consuming less energy unless the speed optimization causes the energy per cycle to be significantly higher. In theory, some compiler

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

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

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 Jul 2, 2013, at 2:35 PM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > 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.

Sent from my iPhone On Jun 28, 2013, at 2:38 PM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > 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

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

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.

Let me describe more precisely what I am doing and why the results I got may help improve LLVM's performance on modern x86-64 processors regardless of the front end (GCC, Clang or DragonEgg). I am running ALL my tests on an Intel Xeon E5540 processor, which is an x86-64 Nehalem processor. The OS is a 64-bit version of Ubuntu. So, I am running all my tests on the same x86-64 machine and am

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

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%

Which options are you seeing that cause the largest difference, and on which targets? As Chandler mentioned there has been a large amount of variation in x86 targets, and there are certain optimizations that can be done, on say a Pentium (scheduling instructions which are pairable and non-dependent so the U and V pipelines are saturated without contention, for example) that don't make sense

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,