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

[David Greene via llvm-dev]

Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes:

> So, IIGIR, initially, this would consolidate the prefetching
> infrastructure, which is a worthy goal in itself and would require a
> minimalist implementation for now.

Yes.

> But later, vectorisers could use that info, for example, to understand
> how much would be beneficial to unroll vectorised loops (where total
> access size should be a multiple of the cache line), etc.

Exactly!

> Ultimately, simulations would be an interesting use of it, but
> shouldn't be a driving force for additional features bundled into the
> initial design.

I agree simulation isn't the primary motivation, but it's a nice
side-effect.

We use all of these parameters today, so they are useful.

> But it's worse, because different releases of the same family can have
> different core counts, change model (clustered/bundled/heterogeneous)
> and there's no way to currently represent that in table-gen.

Yes, this is exactly the SKU problem I mentioned.  I don't have a good
solution for that other than to say that we've found that a generic
model per major subtarget can work well enough across different SKUs.
As currently constructed, the model is intended to be a resource for
heuristics, so getting things wrong is "just" a performance hit.

I guess it would be up to the people interested in a particular target
to figure out a reasonable, maintainable way to manage models for
possibly many subtargets.  This proposal is about providing
infrastructure to allow models to be created with not too much effort.
It doesn't say anything about what models for a particular
target/subtarget should look like.  :)

> Given that the kernel has such a high influence how those cores get
> scheduled and preempted, I don't think there's any hope that the
> compiler can do a good job at predicting usage or having any real
> impact amidst higher level latency, such as context switches and
> systemcalls.

Sure.  In those cases a model isn't that useful.  Not every subtarget
needs to have a model.  Alternatively, a simple "dumb" model could be
used for such targets, setting prefetch parameters, etc. to something
not totally outrageous.  The prefetcher, for example, would have to
check if a model exists.  If not, it wouldn't prefetch.

                               -David