This is an archive of the discontinued LLVM Phabricator instance.

[LICM] Precompute memory writers for AST aliasing analysis
AbandonedPublic

Authored by mkazantsev on Apr 24 2020, 4:29 AM.

Details

Summary

Current aliasing algorithm with AST traverses through all instructions in the loop
whenever it sees a load. However, the only instructions it really needs to check is
memory writing instructions. In this patch, we precompute a set of memory writers
and keep it up to date, avoiding redundant checks.

This patch is NFC for current default (zero) threshold and profitable when loop
has more than 1 load and total loop size is below limit. In current implementation,
it may cause redundant computations when loop exceeds the limit and this limit is
non-zero. Need to think how to tackle this.

This gives us up to 25% speedup on some extreme case in big loop with many loads
and few writing instructions.

Diff Detail

Event Timeline

mkazantsev created this revision.Apr 24 2020, 4:29 AM
mkazantsev marked an inline comment as done.Apr 24 2020, 4:31 AM
mkazantsev added inline comments.
llvm/lib/Transforms/Scalar/LICM.cpp
2246

Currently, None here means either:

  • it was called outside of LICM and no one really tried recompute writers;
  • the writer computation has hit the limit.

We don't really need to do this in latter case. But I could not find any smart way to convey this info. Any design advice here is welcome.

One general comment: could this use case be added only when using AST (the creation of the set, updating it, etc)? It could even be included in the AST creation/update, or push inside the eraseInstruction calls if it's easier to have a common place to add it.
Otherwise this is adding unnecessary overhead when using MemorySSA, which is the current default.

The usecase for this improvement sounds very interesting. Could you provide more details about it and how using MemorySSA compares to the AST in this case?

llvm/lib/Transforms/Scalar/LICM.cpp
782

Would this also be useful inside sinkRegion(), or have it precomputed outside the calls?

One general comment: could this use case be added only when using AST (the creation of the set, updating it, etc)?

Good catch, will do!

The usecase for this improvement sounds very interesting. Could you provide more details about it and how using MemorySSA compares to the AST in this case?

I'm planning to check; in the past there were some functional problems with MSSA in our environment but by now they could have been fixed. I'll post you up to date when I have the results!

Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2020, 9:00 PM
mkazantsev marked an inline comment as done.Apr 26 2020, 9:04 PM
mkazantsev added inline comments.
llvm/lib/Transforms/Scalar/LICM.cpp
782

Need to check, thanks for catching this.

Regarding MSSA: in my setup (we use custom pipeline, LICM takes ~8% total time) this patch gives 1% total and mean compile time decrease on workload (approx. 12.5% of LICM time). Turning on MSSA for all loop passes causes ~6% total and mean compile time increase. MSSA doesn't give any performance gains on my test. However I am not sure how representative this workload is, we might have gains in some other case.

mkazantsev added a reviewer: asbirlea.

Addressed comments.

Looks good overall, just a few nits inline.

llvm/lib/Transforms/Scalar/LICM.cpp
143

Optional<DenseSet<Instruction *> > clang-format adds that space between > >?
It's consistent throughout, so I guess so...it just looks odd to me :-).

313

Does it make sense to create the DenseSet here and pass it to the sinkRegion and hoistRegion below, instead of creating in each?

It may save some time to only create once if the set it properly updated after each of those calls, but then it's also expanding the signature of sinkRegion and hoistRegion.
An option may be to put the set inside a data structure, such as the SinkAndHoistLICMFlags?

811

NIt: no braces

1563

Nit: no braces.

1645

Nit: no new line needed.

1666

Nit: no braces.

mkazantsev marked 2 inline comments as done.May 8 2020, 3:33 AM
mkazantsev added inline comments.
llvm/lib/Transforms/Scalar/LICM.cpp
143

Will double-check, but I guess it was clang-format.

313

I also was considering it and didn't do it because of impact on sink/hoistRegion API. I will take another look, maybe we can indeed encapsulate it somewhere.

mkazantsev marked an inline comment as done.May 8 2020, 3:40 AM
mkazantsev added inline comments.
llvm/lib/Transforms/Scalar/LICM.cpp
811

Good catch, its a remnant of logging that was there. :)

mkazantsev marked an inline comment as done.May 8 2020, 3:44 AM
mkazantsev added inline comments.
llvm/lib/Transforms/Scalar/LICM.cpp
143

Yes, it must be legacy since times where C++ parser was confusing <X <Y>> with shift. :)

mkazantsev abandoned this revision.Sep 15 2020, 9:10 PM