This is an archive of the discontinued LLVM Phabricator instance.

NFC: Migrate LoopUnrollPass to work on InstructionCost
ClosedPublic

Authored by sdesmalen on Feb 1 2021, 1:39 PM.

Details

Summary

This patch migrates cost values and arithmetic to work on InstructionCost.
When the interfaces to TargetTransformInfo are changed, any InstructionCost
state will propagate naturally.

See this patch for the introduction of the type: https://reviews.llvm.org/D91174
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html

Diff Detail

Event Timeline

sdesmalen created this revision.Feb 1 2021, 1:39 PM
sdesmalen requested review of this revision.Feb 1 2021, 1:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2021, 1:39 PM
david-arm accepted this revision.Feb 2 2021, 1:21 AM

LGTM!

This revision is now accepted and ready to land.Feb 2 2021, 1:21 AM
fhahn added a subscriber: fhahn.Feb 2 2021, 1:23 AM
fhahn added inline comments.
llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
650

should we add an accessor that returns the value directly? The extra dereferences look odd, especially because we already check that the cost is valid.

sdesmalen added inline comments.Feb 2 2021, 4:47 AM
llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
650

When @david-arm created the class I initially argued against that because I didn't want people to assume getValue() always returns a value, and crashes when the value isn't valid. I agree with you that the current interface is cumbersome in these cases, but fortunately this use-case is quite rare; in most places InstructionCost is either propagated, accumulated or compared directly.

I could add some getValidValue() where the name hints the cost must be valid (and where the method asserts it is), but given the limited use-cases in practice, I think I still prefer to stick to the current interface where it returns an Optional, because that makes it unequivocally clear the value may not be set if the InstructionCost is invalid.

fhahn added inline comments.Feb 2 2021, 5:02 AM
llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
650

Is it that uncommon? It looks like the majority of uses in LoopVectorize.cpp for example use *Cost.getValue() for example.

sdesmalen added inline comments.Feb 2 2021, 5:04 AM
llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
650

That's only temporary, until we finish migrating places to work with InstructionCost directly, so most of these *Cost.getValue() statements will go away.

fhahn accepted this revision.Feb 3 2021, 12:44 AM

LGTM

llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
650

Ok, sounds like it's probably not worth worrying about it too much then.

This revision was landed with ongoing or failed builds.Feb 4 2021, 6:06 AM
This revision was automatically updated to reflect the committed changes.