This is an archive of the discontinued LLVM Phabricator instance.

[LV] Compute ranges for plans up front (NFC).
AbandonedPublic

Authored by fhahn on Mar 18 2021, 3:14 AM.

Details

Reviewers
Ayal
gilr
rengolin
Summary

This patch introduces a new helper to compute the ranges of VFs with
matching decisions for all instructions up front. This will be used in a
follow-up patch to get rid of the VF range clamping during recipe
creation, enabling us to move to more granular VPlan construction.

The current version just adds the new helper and adds assertions to
ensure it gives the same result as the current clamping, in order to
catch any potential gaps.

This extra work is only needed temporarily and it appears to be
compile-time neutral:
http://llvm-compile-time-tracker.com/compare.php?from=7c7f4676cd421b1d64145eebfed11e5a3d8935d7&to=80d7088723fcfcd4ac80235bdbd57b70156b997f&stat=instructions

Note that this means the logic to apply the decisions is becoming a bit
more spread out initially. But in future patches, we can do the
decisions exclusively up-front (e.g. by creating a map which contains
whether to widen, scalarize or clone for each instruction in the loop).
This would allow us to untangle recipe creation from the cost-model
specifics as follow-up.

Diff Detail

Event Timeline

fhahn created this revision.Mar 18 2021, 3:14 AM
fhahn requested review of this revision.Mar 18 2021, 3:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 18 2021, 3:14 AM
Herald added a subscriber: vkmr. · View Herald Transcript
Ayal added a comment.Mar 27 2021, 3:06 AM

Thanks @fhahn for moving this forward!
Have mostly minor nits.

llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
208

This cleanup is independent?

300

vector factor >> vectorization factor (x2)

303

computeRanges >> computeVFRanges

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1602

Ideally these bool CM.should*(inst, VF) methods would be const, but that seems to require various other methods to be const as well?

1639

will be should be >> should be scalarized

8475

Note that folding the above VF-agnostic early-exit into the lambda below may cause some overhead - no need to scan the entire range to realize it will not be clamped. But as your measurements confirm this is insignificant.

8511

Should one-liner 'willWiden()' lambda's be folded inline into getDecisionAndClampRange() as in IsPredicated above?

8528–8529

How about 'ShouldScalarize' >> 'willWiden' returning !CM.shouldScalarize(), to be more consistent with the above?

8718

// Split the [Start, End) Range at Idx into [Start, VF*2) and [VF*2, End)

by clamping the End of the existing Range and introducing a new range.
Can Range.Start continue to be const?

8747

Better scan basic-blocks in regular DFS order, avoid RPO.

8772

Widened >> Widen

Better first set Widen = CM.*(Instr, VF) and then set Split = (Widen == CM.*(Instr, VF*2)) throughout?

8775

Use Instr or &I consistently?

8783

second VF should be VF * 2
(calls for a test?)

Alternatively check if getWideningDecision's agree, thereby also covering CM_Interleave case?

Outline into Split = !CM.dicisionsAgree(Instr, VF, VF*2) ?

8788

if (!Widen && !Split) { ?

8792

Also need to make sure isScalarWithPredication() are identical?
Originally affects clamping in tryToWidenCall() and handleReplication().

8821

This calls for a Range::operator==, but is needed only temporarily, right?

llvm/lib/Transforms/Vectorize/VPlan.h
72

Is this change needed?
Update above comment given that Start is also adjustable?

llvm/test/Transforms/LoopVectorize/X86/phis-only.ll
7

Worth mentioning the purpose of the test, possibly by renaming the function name?
%0 is dead?

fhahn updated this revision to Diff 333720.Mar 28 2021, 7:06 AM

Address comments, thanks!

fhahn marked 11 inline comments as done.Mar 28 2021, 7:15 AM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
208

Unfortunately not at the moment. it is still used during the widening checks in tryToWidenCall I think.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1602

I pushed a few NFC commits changing the used methods to const . Now shouldWiden.* can be const as well.

8718

Unfortunately it cannot, because Ranges.insert needs to be able to overwrite existing entries I think.

8747

I think we can just iterate over the loop blocks. I removed the DFS/RPO.

8775

Instr is gone.

8783

(calls for a test?)

yes, but unfortunately I could not construct a test case where it only comes down to whether the decisions agree for a memory operation. for example, it is possible to have a case where we switch from interleave-group to widen, but in that case the recipe for the GEP also changes.

8821

yes it's just temporary. I can add Range::operator==, but I think it would become unused, after the next patch goes in.

llvm/lib/Transforms/Vectorize/VPlan.h
72

Unfortunately yes, because Ranges.insert needs to overwrite existing elements.

We should be able to limit modifications once the clamping is gone, but using a vector of const VFRange.

llvm/test/Transforms/LoopVectorize/X86/phis-only.ll
7

Done, I added a comment and adjusted the check lines to check for a plan including all VFs.

fhahn updated this revision to Diff 333721.Mar 28 2021, 7:15 AM
fhahn marked 3 inline comments as done.

Adjust comment for VFRange.

fhahn abandoned this revision.Apr 27 2021, 4:15 AM

I changed focus on transitioning sinking of scalar operands to a VPlan-to-VPlan transform in D100258.