This is an archive of the discontinued LLVM Phabricator instance.

[TTI] Unify FavorPostInc and FavorBackedgeIndex into getAddressingMode
ClosedPublic

Authored by SjoerdMeijer on Feb 12 2021, 6:02 AM.

Details

Summary

This refactors shouldFavorPostInc() and shouldFavorBackedgeIndex() into getAddressingMode() so that we have one interface to steer LSR in generating the preferred addressing mode.

Diff Detail

Event Timeline

SjoerdMeijer created this revision.Feb 12 2021, 6:02 AM
SjoerdMeijer requested review of this revision.Feb 12 2021, 6:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2021, 6:02 AM

Shouldn't this be an NFC..? Looks like we should be favouring post-incs for MVE, even at optsize.

llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
1263

else if

Yeah, it should be NFC, but there's some interaction with OptSize that makes this behave slightly different.
Now returning PostIndexed for OptSize, which shows some codegen differences, but they seem to be the right changes.

But why not just order the logic so that it is an NFC?

dmgreen added inline comments.Feb 12 2021, 8:14 AM
llvm/include/llvm/Analysis/TargetTransformInfo.h
648

I feel like the name is too general, and should be most specific to this favoring one mode or the other in LSR. Maybe just adding Preferred or Favor to it would be enough.

llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
108

Is this not still different for optsize?

108–116

I don't think this should be needed?

110

Doesn't need the else after a return.

Thanks, renamed it to getPreferredAddressingMode and simplified the logic in the ARM implementation.

LGTM, unless Sam has any other comments.

llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
112

This needn't check hasMVEIntegerOps, if it's returning PostIndexed above.

Nothing else from me.

Thanks guys, I have added ScalarEvolution *SE to the interface to make it a bit more general (so implementation can e.g. query getInductionVariable)

dmgreen accepted this revision.Feb 15 2021, 1:59 AM

That sounds OK. Like I said if you want to do any amount of processing in getPreferredAddressingMode then it probably needs to be caching the result. Cost::RateRegister is called a lot of times for some loops.

This revision is now accepted and ready to land.Feb 15 2021, 1:59 AM

Thanks Dave, I will keep that in mind and will look into it when I'll get to it. My first thought would not to call it inside RateRegister, that seems unnecessary, so yes, either that or some caching.