This is an archive of the discontinued LLVM Phabricator instance.

[LV] Ignore candidate VFs with invalid costs.
ClosedPublic

Authored by sdesmalen on Jul 6 2021, 5:01 AM.

Details

Summary

This follows on from discussion on the mailing-list:

https://lists.llvm.org/pipermail/llvm-dev/2021-June/151047.html

to interpret an Invalid cost as 'infinitely expensive', as this
simplifies some of the legalization issues with scalable vectors.

Diff Detail

Event Timeline

sdesmalen created this revision.Jul 6 2021, 5:01 AM
sdesmalen requested review of this revision.Jul 6 2021, 5:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 6 2021, 5:01 AM
dmgreen added inline comments.Jul 7 2021, 2:16 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6082–6083

Is this comment still useful? It doesn't seem to relate to the code here.

6091–6092

Do we usually add llvm instructions to optimization reports? Or do they usually use debug info for anything they print?

8025–8026

Reflow comment.

Will this work for reductions if it's placed here? Can an inloop reduction have an invalid cost? Or are they OK because there is a target hook for them?

sdesmalen updated this revision to Diff 357212.Jul 8 2021, 6:53 AM

Removed stale comment.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6082–6083

Good spot, I've removed it.

6091–6092

It is not common, but there is certainly precedent for it. For example:

llvm/test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll:

; FALLBACK-WITH-REPORT-ERR: remark: <unknown>:0:0: unable to legalize instruction: G_STORE %3:_(<3 x s32>), %4:_(p0) :: (store 12 into %ir.addr + 16, align 16, basealign 32) (in function: odd_vector)

llvm/test/CodeGen/X86/fast-isel-abort-warm.ll:

; CHECK: remark: <unknown>:0:0: FastISel missed call:   call void asm sideeffect
8025–8026

It would, although at the moment the code in getInstructionCost seems to ignore the Invalid returned by getReductionPatternCost, so that will need a bit of work. It's fine though, since the canVectorizeReductions function (which calls a TTI hook) covers this case already.

dmgreen added inline comments.Jul 9 2021, 5:00 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1643–1644

There's only one use of hasInvalidCosts, and it doesn't use Invalid. Is it worth just using expectedCost directly?

6075

Can this use InstructionCost::max() now?

6091–6092

OK. It would simplify it a bit to not have to record the "invalid" instructions.

Do we usually add opt remarks for the costs at each factor? It sounds useful to be honest, but I don't see it anywhere.

Can we split the opt remarks out into a separate patch, to keep this first one simpler.

8025–8026

Oh yeah, that function could probably do with separating out the "did not find a pattern" vs an invalid cost.

Still reflow the comment.

sdesmalen updated this revision to Diff 357518.Jul 9 2021, 8:19 AM
sdesmalen marked 4 inline comments as done.

Split out the code to emit remarks, so we can add this in a separate patch.

sdesmalen added inline comments.Jul 9 2021, 8:20 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1643–1644

Could do, but that means making expectedCost public instead of private. I wasn't sure if there was a specific reason these cost-queries were private.

6075

Yes! Good catch. I've made the change in D105113 where it belonged in the first place.

6091–6092

Do we usually add opt remarks for the costs at each factor? It sounds useful to be honest, but I don't see it anywhere.
Can we split the opt remarks out into a separate patch, to keep this first one simpler.

Sure will do. Perhaps we can collate some of this information to print a more concise report, without having to print remarks for each factor, for example:

remark: Not all VFs are feasible due to invalid costs for:
  call @llvm.sin(...) (at VF=vscale x 2)

Or when it cannot use scalable vectors for any of the candidate VFs:

remark: Could not vectorize with scalable vectors because none of the candidate VFs result in a valid cost:
  mul i64 %reduction, %val (at VF=vscale x 1, vscale x 2, vscale x 4)
  call @llvm.sin(...) (at VF=vscale x 2)

Thanks. This looks good to me minus one nit about having selectUserVectorizationFactor return the success/failure directly.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1643–1644

Oh I see. I hadn't noticed that expectedCost was private.

In that case can we make selectUserVectorizationFactor return a bool indicating whether it can select that user factor? So a true/false on success depending on the illegal cost. That should be able to use any private methods, and it makes sense to me for the method to return false if it cannot successfully pick that UserVF.

sdesmalen marked an inline comment as done.Jul 9 2021, 9:36 AM
sdesmalen added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
1643–1644

I like that suggestion, thanks!

sdesmalen updated this revision to Diff 357546.Jul 9 2021, 9:36 AM
sdesmalen marked an inline comment as done.

Changed selectUserVectorizationFactor to return a bool to indicate if the UserVF is feasible.

dmgreen accepted this revision.Jul 9 2021, 9:39 AM

Thanks, this LGTM.

I would remove hasInvalidCosts and use expectedCost directly, but that's up to you.

This revision is now accepted and ready to land.Jul 9 2021, 9:39 AM
sdesmalen updated this revision to Diff 357700.Jul 10 2021, 3:27 AM

Removed hasInvalidCosts.

This revision was landed with ongoing or failed builds.Jul 12 2021, 1:59 AM
This revision was automatically updated to reflect the committed changes.