Re: [PATCH v2] Target-independent store forwarding avoidance.

[Philipp Tomsich <philipp.tomsich@vrull.eu>]

On Tue, 11 Jun 2024 at 15:37, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 6/11/24 1:22 AM, Richard Biener wrote:
>
> >> Absolutely.   But forwarding from a smaller store to a wider load is painful
> >> from a hardware standpoint and if we can avoid it from a codegen standpoint,
> >> we should.
> >
> > Note there's also the possibility to increase the distance between the
> > store and the load - in fact the time a store takes to a) retire and
> > b) get from the store buffers to where the load-store unit would pick it
> > up (L1-D) is another target specific tuning knob.  That said, if that
> > distance isn't too large (on x86 there might be only an upper bound
> > given by the OOO window size and the L1D store latency(?), possibly
> > also additionally by the store buffer size) attacking the issue in
> > sched1 or sched2 might be another possibility.  So I think pass placement
> > is another thing to look at - I'd definitely place it after sched1
> > but I guess without looking at the pass again it's way before that?
> True, but I doubt there are enough instructions we could sink the load
> past to make a measurable difference.  This is especially true on the
> class of uarchs where this is going to be most important.
>
> In the case where the store/load can't be interchanged and thus this new
> pass rejects any transformation, we could try to do something in the
> scheduler to defer the load as long as possible.  Essentially it's a
> true dependency through a memory location using must-aliasing properties
> and in that case we'd want to crank up the "latency" of the store so
> that the load gets pushed away.
>
> I think one of the difficulties here is we often model stores as not
> having any latency (which is probably OK in most cases).  Input data
> dependencies and structural hazards dominate dominate considerations for
> stores.

I don't think that TARGET_SCHED_ADJUST_COST would even be called for a
data-dependence through a memory location.

Note that, strictly speaking, the store does not have an extended
latency; it will be the load that will have an increased latency
(almost as if we knew that the load will miss to one of the outer
points-of-coherence).  The difference being that the load would not
hang around in a scheduling queue until being dispatched, but its
execution would start immediately and take more cycles (and
potentially block an execution pipeline for longer).

Philipp.