[PATCH] D90687: [LV] Ignore VF hint when unsafe
Michael Kruse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 3 09:58:24 PST 2020
Meinersbur added a comment.
`#pragma clang loop vectorize_witdh(..)` ignoring safety checks is indeed bad. Instead of not vectorizing at all in this case, did you consider using `min(UserVF,FeasibleVF)` instead?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:5238
+ if (!VectorizerParams::isVFForced() && UserVF &&
+ UserVF > computeFeasibleMaxVF(TC)) {
+ reportVectorizationFailure(
----------------
fhahn wrote:
> dmgreen wrote:
> > I don't think computeFeasibleMaxVF is the maximum safe width. It does a lot of things and is largely based on the backend vector widths. I'm guessing that's why so many tests are changing.
> >
> > It should probably be based on Legal.getMaxSafeRegisterWidth()?
> > It should probably be based on Legal.getMaxSafeRegisterWidth()?
>
> computeFeasibleMaxVF should only return legal vectorization factors (using getMaxSafeRegisterWidht) I think. Given that we are free to ignore the hint, if it is not useful, why not just use the largest safe vectorization factors instead of bailing out?
>
> Unfortunately the handling of UserVF is a bit of a mess, but I think it might be preferable to clamp the UserVF to the maximum vectorization factor in the caller of computeMaxVF where UserVF is actually used.
`Legal.getMaxSafeRegisterWidth()` is called within `computeFeasibleMaxVF`. With `computeFeasibleMaxVF` considering additional architecture concerns, can these be just ignored?
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:5238
+ if (!VectorizerParams::isVFForced() && UserVF &&
+ UserVF > computeFeasibleMaxVF(TC)) {
+ reportVectorizationFailure(
----------------
Meinersbur wrote:
> fhahn wrote:
> > dmgreen wrote:
> > > I don't think computeFeasibleMaxVF is the maximum safe width. It does a lot of things and is largely based on the backend vector widths. I'm guessing that's why so many tests are changing.
> > >
> > > It should probably be based on Legal.getMaxSafeRegisterWidth()?
> > > It should probably be based on Legal.getMaxSafeRegisterWidth()?
> >
> > computeFeasibleMaxVF should only return legal vectorization factors (using getMaxSafeRegisterWidht) I think. Given that we are free to ignore the hint, if it is not useful, why not just use the largest safe vectorization factors instead of bailing out?
> >
> > Unfortunately the handling of UserVF is a bit of a mess, but I think it might be preferable to clamp the UserVF to the maximum vectorization factor in the caller of computeMaxVF where UserVF is actually used.
> `Legal.getMaxSafeRegisterWidth()` is called within `computeFeasibleMaxVF`. With `computeFeasibleMaxVF` considering additional architecture concerns, can these be just ignored?
With `computeFeasibleMaxVF` already called later, could you store its result for both uses?
I suggest to move `UserVF ? UserVF : computeFeasibleMaxVF(TC)` which is duplicated multiple times below before this condition. Such as:
```
auto MaxVF = computeFeasibleMaxVF(TC);
if (UserVF) {
if (UserVF > MaxVF) {
...
}
MaxVF = UserFC;
}
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90687/new/
https://reviews.llvm.org/D90687
More information about the llvm-commits
mailing list