This is an archive of the discontinued LLVM Phabricator instance.

[LV] NFCI: Do cost comparison on InstructionCost directly.
ClosedPublic

Authored by sdesmalen on Jun 29 2021, 6:19 AM.

Details

Summary

Instead of performing the isMoreProfitable() operation on
InstructionCost::CostTy the operation is performed on InstructionCost
directly, so that it can handle the case where one of the costs is
Invalid.

This patch also changes the CostTy to be int64_t, so that the type is
wide enough to deal with multiplications with e.g. unsigned MaxTripCount.

Diff Detail

Event Timeline

sdesmalen created this revision.Jun 29 2021, 6:19 AM
sdesmalen requested review of this revision.Jun 29 2021, 6:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 29 2021, 6:19 AM

i64 for the type sounds OK to me. (The old methods was known not to overflow because of divideCeil being a int64_t and the other values being int32. But with saturation that should be fine now too)

Does this mean that invalid costs now don't vectorize? (For an invalid vector cost)

Is it possible to add a test for that?

i64 for the type sounds OK to me. (The old methods was known not to overflow because of divideCeil being a int64_t and the other values being int32. But with saturation that should be fine now too)

Does this mean that invalid costs now don't vectorize? (For an invalid vector cost). Is it possible to add a test for that?

Not yet, that requires a few more code-changes. The behaviour to avoid vectorization with Invalid costs is added in D105473 (with corresponding tests and some logic to print out useful opt-remarks).

This patch is intended to be NFC (I'll add NFCI to the title of the patch)

sdesmalen retitled this revision from [LV] Do cost comparison on InstructionCost directly. to [LV] NFCI: Do cost comparison on InstructionCost directly..Jul 6 2021, 5:06 AM
dmgreen added inline comments.Jul 7 2021, 2:16 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6597

These still use unsigned. Are we happy to assume that getRegUsageForType / getTypeLegalizationCost will always produce a small, sensible value?

sdesmalen added inline comments.Jul 7 2021, 2:33 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6597

Yes, I think it's safe to assume that, but I'd be happy to add an assert for it if you think that's worth it?

sdesmalen updated this revision to Diff 357211.Jul 8 2021, 6:52 AM

Added assert to ensure the range of getRegisterUsage is sensible.

dmgreen accepted this revision.Jul 8 2021, 11:00 AM

Thanks. The assert sounds good. LGTM

This revision is now accepted and ready to land.Jul 8 2021, 11:00 AM
sdesmalen updated this revision to Diff 357517.Jul 9 2021, 8:16 AM

Replaced std::numeric_limits<InstructionCost::CostTy>::max()
by InstructionCost::getMax()

As suggested in D105473.

This revision was landed with ongoing or failed builds.Jul 10 2021, 4:23 AM
This revision was automatically updated to reflect the committed changes.