This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Introduce VPWidenIntOrFpInductionRecipes to original plan.
Changes PlannedPublic

Authored by fhahn on Mar 1 2021, 11:23 AM.

Details

Reviewers
gilr
rengolin
Ayal
Summary

Some VPInstructions are converted to recipes regardless of the
vectorization factor. Perform the conversion on the initial/original
plan. This patch does so for VPWidenIntOrFpInductionRecipes

Diff Detail

Event Timeline

fhahn created this revision.Mar 1 2021, 11:23 AM
fhahn requested review of this revision.Mar 1 2021, 11:23 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2021, 11:23 AM
Herald added a subscriber: vkmr. · View Herald Transcript
a.elovikov added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8874

nit: can we use make_early_inc_range here isntead?

8885

Are these modifications to OriginalPlan expected to be done in all the transformations that replace the recipes? If so, I'm afraid that it would be error-prone and would decrease readability of the code.

I'm not familiar with the code to understand why it's needed (yet) so my question might not make much sense, but still. Is it possible we can "hide" those details by making a higher-level interface? Or are we expecting that such maintenance wouldn't be needed once we uplift VPlan to full VPValue-based/more independent of the original LLVM IR?

Kazhuu added a subscriber: Kazhuu.Mar 3 2021, 8:42 PM
fhahn updated this revision to Diff 335339.Apr 5 2021, 3:04 PM

Rebased and simplified.

fhahn added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8885

Are these modifications to OriginalPlan expected to be done in all the transformations that replace the recipes? If so, I'm afraid that it would be error-prone and would decrease readability of the code.

Yes, unfortunately there are still a few places that rely on accessing the VPValue via the underlying value, mostly to fix up phis after executing the VPlan. The plan is to update those places to deal with recipes directly, hence not having to access the VPValue through the underlying value.

This means at the moment, the code is a bit bigger than it will be in the end but it is just temporary so we don't have to block progress in multiple directions. For example, D99293 removes the need to use getVPValue with an underlying IR value when fixing reduction PHIs (except for the value for the loop-exit instruction).

fhahn planned changes to this revision.May 16 2021, 10:48 AM

Putting this on hold for now, to first focus on sinking scalar operands as VPlan-to-VPlan transform: D100258