similar to: [LLVMdev] Memory Subsystem Representation

On Tue, May 3, 2011 at 8:40 AM, David Greene <dag at cray.com> wrote: > For a while now we (Cray) have had some very primitive cache structure > information encoded into our version of LLVM.  Given the more complex > memory structures introduced by Bulldozer and various accelerators, it's > time to do this Right (tm). > > So I'm looking for some feedback on a

Hi Dave, Can you describe which passes may benefit from this information ? My intuition is that until there are a number of passes which require this information, there are other ways to provide this information. One way would be to use Metadata. Having said that, I do share the feeling that IR-level optimization often need more target-specific information. For example, vectorizing compilers

Hi, thank you for sharing the system hierarchy model. IMHO it makes a lot of sense, although I don't know which of today's passes would make use of it. Here are my remarks. I am wondering how one could model the following features using this model, or whether they should be part of a performance model at all: * ARM's big.LITTLE * NUMA hierarchies (are the NUMA domains

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

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

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

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]

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

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

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

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

After several years I replaced desktop and laptop and wait for release to start fresh. On desktop I put nvidia gt520. Forums say nvidia prop driver dislikes agp op- tion in kernel and recommend removing it. Laptop is sandy bridge with hd3000 integrated. Would I trigger something if I delete agp from conf file in both cases? Another issue bothers me also. RC version of amdtemp failed to read

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

Hello, is there a way in which I can use text labels rather than numbers on the x axis ticks? I basically have a vector of (say) 8 points and I want to plot these sequentially. Thus the x axis would have ticks at 1 .. 8. Rather than having the labels 1 .. 8 I would like to have some arbitrary text labels. Ideally I would like the labels to be rotated (say at 45 degrees) so that they don't

Hello, is there a way in which I can use text labels rather than numbers on the x axis ticks? I basically have a vector of (say) 8 points and I want to plot these sequentially. Thus the x axis would have ticks at 1 .. 8. Rather than having the labels 1 .. 8 I would like to have some arbitrary text labels. Ideally I would like the labels to be rotated (say at 45 degrees) so that they don't

Hello, if I compile with dragonegg and -march=native I get this message: 'bdver1' is not a recognized processor for this target (ignoring processor) Is there any plan to support this cpu ? Here the full example the source file doesn't matter. gcc -s -static -Wall -O2 -march=native -fplugin=dragonegg.so -fplugin-arg-dragonegg-enable-gcc-optzns pointer.c -o pointer

Tom , Thank you for correcting me here , All , Please review the changes made and is it ok to commit ?? Thanks ~Umesh On Thu, Nov 21, 2013 at 11:47 PM, Tom Stellard <tom at stellard.net> wrote: > Hi Umesh, > > You should send patches to llvm-commits at cs.uiuc.edu, also each patch > should be its own plain-text attachment. > > -Tom > > On Thu, Nov 21, 2013 at

On May 5, 2011, at 3:27 PM, David A. Greene wrote: >> This sounds like an interesting addition, but we don't just >> speculatively add analysis passes to LLVM. > > Well, we do have such an analysis pass. I simply can't make it public. > My plan was to provide the information we use today and leave > enhancements to others as they are needed. The point of having

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

Chris Lattner <clattner at apple.com> writes: > On May 3, 2011, at 12:01 PM, David A. Greene wrote: > >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: >> >>> Can you describe which passes may benefit from this information ? My >>> intuition is that until there are a number of passes which require >>> this information, there