[PATCH] D69040: [TTI][LV] preferPredicateOverEpilogue

[Sjoerd Meijer via Phabricator via llvm-commits]

SjoerdMeijer updated this revision to Diff 227444.
SjoerdMeijer added a comment.

I have:

- changed the ARM implementation to check the required architecture extensions: check for MVE, the remaining checks are done in `isHardwareLoopProfitable` so there was no point in duplicating that.
- added a new test case, to cover testing these architecture extension combo's, and profitability check.

@samparker, @dmgreen :
I've given it quite some thoughts to see if the current interface of `preferPredicateOverEpilogue` would be good enough to make a well informed decision whether we prefer to predicate or not. For example, questions were if we should also pass the Vectorization Factor (VF), and the vector types, but there are quite a few chicken-and-eggs-problems here. That is, we decide quite early if we want to predicate or not, long before we have calculated the VF, so let alone about the vector types. So, should `preferPredicateOverEpilogue`then possibly return a set of VF candidates, or calculate the VF a lot earlier? Well, possibly, but that's also what the rest of pipeline is trying to figure out. But more importantly, I don't think we need without sacrificing too much. That is, we are going to be conservative anyway and I think the current interface is good  decide on tail-predication in this way:

- we bail if we find operations on `i64`, because we don't support (vector) operations on them,
- we look if the data processing instructions all operate on the same and uniform data types (data type less or equal i32s),
- we look at the loads and stores, and see access strides are the same and in the same directions. This makes sure we don't generate shuffles, which would mess with data elements and possibly masking/tail-predicating the wrong lanes.
- and then we then rely on the vectoriser and the rest of the pipeline to choose a vectorisation factor.

@hsaito :
Many thanks for the suggestion! I will do that right away after this one as a follow up.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69040/new/

https://reviews.llvm.org/D69040

Files:
  llvm/include/llvm/Analysis/TargetTransformInfo.h
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/lib/Analysis/TargetTransformInfo.cpp
  llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
  llvm/lib/Target/ARM/ARMTargetTransformInfo.h
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/ARM/prefer-tail-loop-folding.ll
  llvm/test/Transforms/LoopVectorize/ARM/tail-loop-folding.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D69040.227444.patch
Type: text/x-patch
Size: 14714 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191101/16bc42d1/attachment-0001.bin>