[PATCH] D113209: [LV] Use VScaleForTuning to fine-tune the cost per lane.
Sander de Smalen via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 5 08:15:48 PDT 2021
sdesmalen added inline comments.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:6030
+ // Improve estimate for the vector width if it is scalable.
+ ElementCount EstimatedWidthA = A.Width;
+ ElementCount EstimatedWidthB = B.Width;
----------------
david-arm wrote:
> nit: This is just a suggestion, but it feels a little odd to be rescaling ElementCount by vscale, because this is already implicit for a scalable element count. For example, what we're doing here is taking a <vscale x 4> ElementCount and then multiplying by another vscale so we end up effectively with an ElementCount like <vscale x vscale x 4>. Is it worth just using unsigned values instead?
>
> unsigned EstimatedWidthA = A.Width.getKnownMinValue();
> unsigned EstimatedWidthB = B.Width.getKnownMinValue();
> if (Optional<unsigned> VScale = TTI.getVScaleForTuning()) {
> if (A.Width.isScalable())
> EstimatedWidthA *= VScale.getValue();
> if (B.Width.isScalable())
> EstimatedWidthB *= VScale.getValue();
> }
> ...
>
>
I was a bit worried it would get confusing with using both A.Width.isScalable() in combination EstimatedWidthA, but perhaps splitting it up is more clear as you suggest.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113209/new/
https://reviews.llvm.org/D113209
More information about the llvm-commits
mailing list