[llvm-commits] [PATCH] Add TargetMemoryModel

[Hal Finkel]

----- Original Message -----
> From: dag at cray.com
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: greened at obbligato.org, llvm-commits at cs.uiuc.edu
> Sent: Thursday, January 24, 2013 3:39:01 PM
> Subject: Re: [llvm-commits] [PATCH] Add TargetMemoryModel
> 
> Hal Finkel <hfinkel at anl.gov> writes:
> 
> > I am in favor of including this information; Among other things, I
> > am
> > working on a software prefetching pass that would greatly benefit
> > from
> > this. Is there a reason not to include this as part of the TTI
> > infrastructure?
> 
> What's TTI?

Look at Analysis/TargetTransformInfo.h.

>  I wrote these patches long ago following the general
> design
> of the processor feature tables.  I then ported it to trunk,
> following
> as much as I could the scheduler table design.

Fair enough. I'm glad to see that you're doing this!

> 
> I am certainly open to a better approach.  Would it be worth
> submitting
> the rest of what I have, reviewing it as-is and trying to commit it
> so
> that more people can participate in refining/reworking it?  I have an
> ongoing interest in these models so it won't be a dump and run.  :)

I'm not sure; but it would be useful to see the rest of what you have. This would provide context to what you're proposing.

> 
> > In addition, the prefetcher info should be cache-level specific.
> > Many
> > systems have different prefetchers for different cache levels.
> 
> The prefetcher information is purely configuration information for a
> software prefetcher.  It is not a model of any hardware prefetcher.
>  The
> way we've written our prefetcher, the distances are guides and we
> account for cache information at whatever prefetch level we're
> targeting.  Again, I am totally open to enhancing what's here if
> people
> have other needs.

Okay, interesting; now I understand. Will you be contributing this prefetcher as well?

> 
> As a follow-on to this series, I have a set of patches to provide
> information about the "execution model" of a target - number of
> cores,
> threads, etc. and the organization of such so that passes may examine
> how much cache they have available per thread and so on.
> 
> > It is also important to know how may requests the prefetcher will
> > generate in response to a stream hit or miss in its target cache
> > level. Some prefetchers will continue to issue requests to fill the
> > stream up to the stream depth as soon as the stream is
> > established. Other prefetchers will only issue N new requests in
> > response to hits or misses of the stream (bounded by the depth).
> 
> I wrote this all assuming purely software prefetching, so it doesn't
> account for hardware prefetchers at all.  Certainly that would be
> useful
> but I don't have those bits yet.  This was originally written for the
> AMD Barcelona series and has been refined over the years for
> follow-on
> targets.  Up until Bulldozer AMD didn't really have a viable hardware
> prefetcher.
> 
> Maybe I should rework the names to emphasize that this is a
> configuration model for software prefetchers, not a model of any
> hardware prefetchers.

Well, do be fair, you did name it TargetSoftwarePrefetcherInfo. It might be better just to call it SoftwarePrefetcherInfo (because it is not a property of the target). Nevertheless, this should be part of TTI so that targets can customize the behavior in the (new) standard way.

Thanks again,
Hal

> 
>                                 -David
>