similar to: [LLVMdev] [PATCH] Bulldozer SchedMachineModel

Dear All, Attached files is related to the changes made to add the Schedmodel for a AMD bulldozer target, Please note that , the model is incomplete but has some of the valuables features implemented. Request to the group or someone from AMD for the comments on the implementation. Thanks ~umesh On Wed, Nov 13, 2013 at 8:14 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote: >

Dear Andrew and the Group, I’m trying come up with a SchedMachineModel for the AMD bulldozer http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture). The model is not exist for the same .Please correct me if am i wrong here. I was going through your reference @ https://llvm.org/svn/llvm-project/llvm/trunk/include/llvm/Target/TargetSchedule.td . But I couldn’t model some of the

Hi Mike, Thank you for the link and my bad last mail has the old patch file. Please have look at the attached patch file herewith,which has the latest changes. i'm new to llvm testing framework and cross compilation as such ,Please can you through some lights like references etc ,Which states that how can i cross compile the llvm for Bulldozer and run the performance test against my

I made a quick cross check with information in the SWOG (Software Optimization Guide). The port assignments look consistent. A few of the latency values are slightly different from the SWOG, e.g. WriteFRcp --> 6, WriteFSqrt --> 29 and WriteCvt* --> 4 seem to be suggested instead. Others are in better position to describe how to use llvm performance framework. --mev, Mike Vermeulen

If you haven't found it yet, the last public AMD Software Optimization Guide for Family 15h is here: http://developer.amd.com/wordpress/media/2012/03/47414_15h_sw_opt_guide.pdf This one describes both Bulldozer and Piledriver processors. Chapter 2 will given an overview of the Microarchitecture and Appendix B gives some additional details on which pipes are used for where. I haven't yet

Better be quick! I am adding FMA4 and XOP now, and if you contribute code before I do, you can spare yourself some XOP merging. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Benjamin Kramer <benny.kra at googlemail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 1, 2011 12:19 PM > Subject: Re: [LLVMdev]

Benjamin Kramer <benny.kra at googlemail.com> writes: > On 30.11.2011, at 08:33, Duncan Sands wrote: > >> Hi Jan, >> >>> if I compile with dragonegg and -march=native I get this message: >>> 'bdver1' is not a recognized processor for this target (ignoring processor) >> >> this is coming directly from LLVM which doesn't know about

On 30.11.2011, at 08:33, Duncan Sands wrote: > Hi Jan, > >> if I compile with dragonegg and -march=native I get this message: >> 'bdver1' is not a recognized processor for this target (ignoring processor) > > this is coming directly from LLVM which doesn't know about bulldozer yet. > >> Is there any plan to support this cpu ? > > I don't

Hi Jan, > if I compile with dragonegg and -march=native I get this message: > 'bdver1' is not a recognized processor for this target (ignoring processor) this is coming directly from LLVM which doesn't know about bulldozer yet. > Is there any plan to support this cpu ? I don't know. Hopefully someone who knows something about this will comment. Ciao, Duncan. >

That is too bad. :(  You can always review the patches, and if you see something that can be done better let me know. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Jan Sjodin <jan_sjodin at yahoo.com> > Cc: David A. Greene <greened at obbligato.org>; Benjamin Kramer <benny.kra at googlemail.com>; "llvmdev at

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

Hi Mehdi, The llvm3.8 gold-plugin.cpp is very different from the latest one on trunk. Your patch has compiling failure on llvm3.8 as below. I will try it on latest trunk later. Thank you help anyway! Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o cd /home/jshi19/llvm38releasebuild/tools/gold && /home/jshi19/clang38/bin/clang++ -DGTEST_HAS_RTTI=0

To recap, this is what I was trying to solve: This C code: int bar(int a, int b, int c, int d, int e, int f); int foo(int a, int b, int c, int d, int e ) { int x = 3*a; return bar3(a,b,c,d,e,x); } Produced the following assembly output: foo: push {r11, lr} sub sp, #8 bl bar add sp, #8 pop {r11, pc} The part I didn't like is that push/pop become

On 05/30/16 01:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > We don't use cl::opt in gold, instead we parse the -plugin-opts that > gold passes the plugin (see process_plugin_option). > What about that: $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp // ParseCommandLineOptions () expects argv[0] to be program name. Lazily cl::

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at

I think emitting "testExt" as an external declaration (what gcc does) doesn't do much for the debugger; being a declaration, it has no location, and so you can't do things like examine its value, unless you find the symbol in the defining CU first. I don't see a real "compatibility with gcc" argument here. Is there some behavior of some consumer that is affected

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH

(And I doubt the GNU linker supports LTO with LLVM). [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070. The new GNU ld linker works well with LLVM/Clang LTO when build IA32 code in my side. And from the ld owner input in the bug comments, the current X64 LLVM LTO issue is in llvm LTO plugin. The fact

Umesh, Makes some sort of sense to me, OTOH: If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH encoding T1 (2 bytes opcode) as opposed to the encoding T2 (which is a 4 bytes opcode). A On Tue, Oct 15, 2013 at 2:59 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote: > Hi