[PATCH] D34963: [AArch64][Falkor] Avoid HW prefetcher tag collisions (step 1)

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D34963#799828, @gberry wrote:

> In https://reviews.llvm.org/D34963#798591, @hfinkel wrote:
>
> > I don't quite understand the design requirements here. Instead of adding custom metadata, would it be better just to have the prefetching pass tag the loads that it believes that it has prefetched? Right now, we only prefetch strided accesses (and I can't tell from your description whether the tag collision problem is specific to strided access because those are what we might prefetch, or because of some other reason).
>
>
> The loads I'm interested in tagging for this series of changes are ones that the LoopDataPrefetch pass has decided *not* to insert SW prefetch instructions for.  For Falkor, we only insert SW prefetch instructions for strided accesses when the stride is known to be too large for the HW prefetchers to handle.  In all other cases, (i.e. when we expect the HW prefetchers to work), there is a separate issue with the HW prefetcher implementation that we want to try to work-around by inserting MOVs very late in the code generation pipeline.
>
> My first prototype of this pass re-arranged the LoopDataPrefetch pass a bit to achieve the same goal (i.e. marking loads that we think the HW prefetcher can handle well), but it seemed like it muddled that pass a bit too much just to address one sub-target's issues.
>
> I don't understand your point about not adding custom metadata.  These loads need to be tagged in some way that will survive (as much as possible) all the way to near the end of code generation.  A custom metadata annotation, translated to a target MMO flag seemed like the cleanest way to achieve this, but I'm certainly open to other suggestions.


Ah, okay, thanks for clarifying. I indeed misunderstood the situation. I don't object to the current direction.


https://reviews.llvm.org/D34963