This is an archive of the discontinued LLVM Phabricator instance.

[LV] Don't vectorize if we can prove RT + vector cost >= scalar cost (alt. version)
Needs ReviewPublic

Authored by ebrevnov on Sep 8 2021, 9:02 AM.

Details

Reviewers
fhahn
Summary

This change does essentially the same thing as D109368 but in a slightly different way. Instead of doing late evaluation of cost of runtime checks in LoopVectorizationPlanner here we do it directly in the CostModel.

Diff Detail

Event Timeline

ebrevnov created this revision.Sep 8 2021, 9:02 AM
ebrevnov requested review of this revision.Sep 8 2021, 9:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 8 2021, 9:02 AM
ebrevnov retitled this revision from [LV][WIP] Don't vectorize if we can prove RT + vector cost >= scalar cost (ver2) to [LV][WIP] Don't vectorize if we can prove RT + vector cost >= scalar cost (alt. version).Sep 8 2021, 10:08 AM
ebrevnov edited the summary of this revision. (Show Details)
ebrevnov added a reviewer: fhahn.

Suppose D109368 lands first.
Is this particular patch an NFC change, or a functional-one?
What i'm asking is, where does this matter?
Can you add tests where the cost of the checks will be radically different for different VF's?

ebrevnov updated this revision to Diff 372200.Sep 13 2021, 3:05 AM

Rebase after cost model restructure

ebrevnov retitled this revision from [LV][WIP] Don't vectorize if we can prove RT + vector cost >= scalar cost (alt. version) to [LV] Don't vectorize if we can prove RT + vector cost >= scalar cost (alt. version).

Suppose D109368 lands first.
Is this particular patch an NFC change, or a functional-one?
What i'm asking is, where does this matter?
Can you add tests where the cost of the checks will be radically different for different VF's?

I greatly reworked this patch since the original questions so not sure if it still matters....Anyway the intention of this patch was to replace D109368. It achieves the same effect by a slightly different way. Namely cost of runtime checks are embedded into main step of cost calculation. Note that we still can land D109368 first and apply this one later (rebase required)

Suppose D109368 lands first.
Is this particular patch an NFC change, or a functional-one?
What i'm asking is, where does this matter?
Can you add tests where the cost of the checks will be radically different for different VF's?

I greatly reworked this patch since the original questions so not sure if it still matters....Anyway the intention of this patch was to replace D109368. It achieves the same effect by a slightly different way. Namely cost of runtime checks are embedded into main step of cost calculation. Note that we still can land D109368 first and apply this one later (rebase required)

I'm not sure this answered my question.

ebrevnov updated this revision to Diff 372643.Sep 15 2021, 12:22 AM

Fixed build error