Page MenuHomePhabricator

[VPlan] Move recipe implementations to separate file (NFC).
ClosedPublic

Authored by fhahn on Jun 16 2022, 7:38 AM.

Details

Summary

This patch moves the code for recipe implementations to a separate file.

The benefits are:

  • Keep VPlan.cpp smaller => faster compile-time during parallel builds.
  • Keep code for logical units together

As a follow-up I am also planning on moving all ::execute
implemetnations from LoopVectorize.cpp over to the new file, which
should help to reduce the size of the file a bit.

Diff Detail

Event Timeline

fhahn created this revision.Jun 16 2022, 7:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 16 2022, 7:38 AM
fhahn requested review of this revision.Jun 16 2022, 7:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 16 2022, 7:38 AM
Herald added a subscriber: vkmr. · View Herald Transcript
Ayal added a comment.Jun 26 2022, 1:47 PM

Nice move! Would it be reasonable to also have a matching VPlanRecipes.h, excluding VPRecipeBase?

llvm/lib/Transforms/Vectorize/VPlan.cpp
38

Hmm, this is not needed at all?

1137

Ah, this #if should stay?

1338

Keep this #endif to end the above #if.

llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
2

File name above and \file description below need to be updated.

262

nit: while we're here, can remove empty line for consistency.

475

nit: remove empty line for consistency.

524

While we're here, and considering additional execute()'s are expected to land here soon: it makes sense to have all methods of a recipe together, including its #if'd print(), and to fuse adjacent #endif/#if pairs of recipes that have only print() defined here. But VPWidenPHIRecipe and VPWidenPointerInductionRecipe have their print() amongst other print()'s and their execute() elsewhere in the file. Would be good to keep the above rules for consistency, or have all print()'s under one #if/#endif given that they look-alike.

fhahn updated this revision to Diff 440193.Jun 27 2022, 6:12 AM
fhahn marked 6 inline comments as done.

Adress latest comments, thanks!

Nice move! Would it be reasonable to also have a matching VPlanRecipes.h, excluding VPRecipeBase?

I think this would require a bit more surgery, as VPlan.h contains multiple function definitions that require the full definition of different recipes types. This could be resovled by moving them to VPlan.cpp, but I think that would be best done separately. Also, I think in most file we would have to include both headers in any case?

llvm/lib/Transforms/Vectorize/VPlan.cpp
38

I don't think so, likely the code using it has been moved somewhere else or has been removed alltogether.

1137

Yes, re-added!

1338

Done, thanks!

llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
2

thanks, should be fixed in the latest version!

262

removed, thanks!

475

Done, thanks!

fhahn marked an inline comment as done.Jun 27 2022, 6:14 AM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
524

I think it would probably be best to keep definitions for a single recipe next to each other. I moved the ::print functions!

Ayal accepted this revision.Jun 27 2022, 9:55 AM

Address latest comments, thanks!

Nice move! Would it be reasonable to also have a matching VPlanRecipes.h, excluding VPRecipeBase?

I think this would require a bit more surgery, as VPlan.h contains multiple function definitions that require the full definition of different recipes types. This could be resolved by moving them to VPlan.cpp, but I think that would be best done separately. Also, I think in most file we would have to include both headers in any case?

Yeah, not much to be gained in terms of reducing compilation time, just to keep things in natural order as much as reasonable.

This revision is now accepted and ready to land.Jun 27 2022, 9:55 AM
This revision was automatically updated to reflect the committed changes.
fhahn marked an inline comment as done.