This is an archive of the discontinued LLVM Phabricator instance.

[Aarch64] Add pass LoopDataPrefetch for Cyclone
ClosedPublic

Authored by anemet on Mar 7 2016, 3:21 PM.

Details

Summary

This wires up the pass for Cyclone but keeps it off for now because we
need a few more TTIs.

The getPrefetchMinStride value is not very well tuned right now but it
works well with CFP2006/433.milc which motivated this.

Tests will be added as part of the upcoming large-stride prefetching
patch.

Diff Detail

Repository
rL LLVM

Event Timeline

anemet updated this revision to Diff 50002.Mar 7 2016, 3:21 PM
anemet retitled this revision from to [Aarch64] Add pass LoopDataPrefetch for Cyclone.
anemet updated this object.
anemet added a reviewer: t.p.northover.
anemet added subscribers: hfinkel, llvm-commits.
anemet added inline comments.Mar 7 2016, 3:28 PM
lib/Target/AArch64/AArch64TargetMachine.cpp
242–243 ↗(On Diff #50002)

Will add a comment here saying that this is only enabled for Cyclone right now since it's the only subtarget that defines a non-zero getPrefetchDistance.

Looks good to me. Tim?

t.p.northover edited edge metadata.Mar 9 2016, 9:47 PM

Yep, I think it looks reasonable for now.

On the longer-term, what are the plans over the cl::opts? They're static initializers which really aren't encouraged, and Cyclone is what it is. If we're still using them for perf-testing on Cyclone (or its descendents), fine.

But otherwise I think they should either be removed or made into tweakables that everyone can experiment with (i.e. the cl::opt overrides everything, Cyclone has a hard-coded 280 if it's not specified).

Cheers.

Tim.

Actually, if we do want cl::opt overrides, they should probably be within the pass itself. I'd be very annoyed as an x86 developer to discover that only AArch64 had the right to fiddle with these values during benchmarking.

Actually, if we do want cl::opt overrides, they should probably be within the pass itself. I'd be very annoyed as an x86 developer to discover that only AArch64 had the right to fiddle with these values during benchmarking.

I think we want them even long term. (The fact they are currently implemented with static initializers is something that will hopefully go away. I remember ChrisB working on this some time ago.) But anyhow your comment is obviously valid.

I can move them to the pass but I guess since they are TTIs they could in theory be used by other passes as well. So logically they would belong more to TTI base class definition...

What do you think? I can start a follow-on llvm-dev thread to discuss it.

Thanks for the reviews.

Adam

Talked to Tim in person, we will probably move these flags into the pass in a follow-on patch.

Tim, can you please officially "accept" the review to allow me to proceed. Thanks!

t.p.northover accepted this revision.Mar 17 2016, 2:43 PM
t.p.northover edited edge metadata.

Sure. Looks fine with that follow-up patch.

Tim.

This revision is now accepted and ready to land.Mar 17 2016, 2:43 PM
This revision was automatically updated to reflect the committed changes.

Talked to Tim in person, we will probably move these flags into the pass in a follow-on patch.

Done in http://reviews.llvm.org/rL264806.

Hal, I also removed -ppc-loop-prefetch-distance in favor of -prefetch-distance in http://reviews.llvm.org/rL264807

  • Original Message -----

From: "Adam Nemet" <anemet@apple.com>
To: anemet@apple.com, "t p northover" <t.p.northover@gmail.com>
Cc: "junmoz park" <junmoz.park@samsung.com>, llvm-commits@lists.llvm.org, "amara emerson" <amara.emerson@arm.com>,
hfinkel@anl.gov, "renato golin" <renato.golin@linaro.org>
Sent: Tuesday, March 29, 2016 6:53:58 PM
Subject: Re: [PATCH] D17943: [Aarch64] Add pass LoopDataPrefetch for Cyclone

anemet added a comment.

In http://reviews.llvm.org/D17943#377625, @anemet wrote:

Talked to Tim in person, we will probably move these flags into the
pass in a follow-on patch.

Done in http://reviews.llvm.org/rL264806.

Hal, I also removed -ppc-loop-prefetch-distance in favor of
-prefetch-distance in http://reviews.llvm.org/rL264807

Great, thanks!

-Hal

Repository:

rL LLVM

http://reviews.llvm.org/D17943