[llvm-dev] RFC: System (cache, etc.) model for LLVM

[Michael Kruse via llvm-dev]

Am Do., 1. Nov. 2018 um 16:56 Uhr schrieb David Greene <dag at cray.com>:
> Ok.  I would like to start posting patches for review without
> speculating too much on fancy/exotic things that may come later.  We
> shouldn't do anything that precludes extensions but I don't want to get
> bogged down in a lot of details on things related to a small number of
> targets.  Let's get the really common stuff in first.  What do you
> think?

I agree.

> > Again, from the Blue Gene/Q: What counts as stream is configurable at
> > runtime via a hardware register. It supports 3 settings:
> > * Interpret every memory access as start of a stream
> > * Interpret a stream when there are 2 consecutive cache misses
> > * Only establish streams via dcbt instructions.
>
> I think we're interpreting "streaming" differently.  In this design, a
> "stream" is a sequence of memory operations that should bypass the cache
> because the data will never be reused (at least not in a timely manner).

I understood "stream" as "prefetch stream", something that prefetch
the data for an access A[i] in a for-loop.

I'd call "bypassing the cache because the data will never be reuse" a
non-temporal memory access.

In the the latter interpretation, what does "number of streams" mean?
AFAIU the processer will just queue memory operations (e.g. for
writing to RAM). Is it the maximum number of operations in the queue?


> >> The intent is that getCacheLevel(0) is the L1 cache, getCacheLevel(1) is
> >> the L2 cache and so on.
> >
> > Can passes rely on it?
>
> Yes.

Naively, I'd put Blue Gene/Q's L1P cache between the L1 and the L2,
i.e. the L1P would be getCacheLevel(1)  and getCacheLevel(2) would be
L2. How would you model it instead?

Michael