As discussed in D57382, interleaving should be avoided if computeMaxVF
returns None, same as we currently do for vectorization.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6477
Differential D57837
[LV] Prevent interleaving if computeMaxVF returned None. fhahn on Feb 6 2019, 12:29 PM. Authored by
Details As discussed in D57382, interleaving should be avoided if computeMaxVF Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6477
Diff Detail
Event TimelineComment Actions I have a little mental barrier in accepting this change as is. I think this feeling of mine is mainly due to the name and the "stated" functionality of computeMaxVF and "indirect inference" towards using it for suppressing interleaving. Maybe I'm just being too picky here. If so, my apologies ahead of time. Other than just the function name and the associated comment:
I think we should start thinking in terms of separate "is vectorization feasible" and "is interleaving feasible" (plus possibly "is unrolling feasible"), even if we evaluate those feasibility in one function. Possibly going to tangent, but while we look at computeMaxVF, at the bottom, we say use pragma, but we bail out of plan() w/o checking whether UserVF exists or not. Hopefully, this conveys enough about my feeling of uneasiness.
Comment Actions Thanks for all the comments! Yep I think so.
Agreed, having it done implicitly in a function called computeMaxVF does not seem ideal. From the current behavior of computeMaxVF, I think what we actually want to decide whether to disable interleaving up front is just if we optimize for size or not. What do you think?
This comment was removed by dcaballe. Comment Actions That was my conclusion as well. With that understanding, your current direction is If VPlan is not built for vectorization purposes, also bail out on interleaving. ---- Work on enabling interleaving in a subsequent patch. and I'm fine with that approach. Comment Actions This patch tries only to avoid running into the "no-VPlan-was-built-for-interleaving" problem, w/o modifying any other behavior or performing any refactoring. The latter indeed deserve to be addressed, but in separate patches. For 1), a same runtime ptr check is needed for both vectorization and interleaving, so seems it should prevent both if one wishes to avoid introducing such branches before a loop when hasBranchDivergence. But I can't find a review explaining r309890.
Comment Actions This LGTM with the minor documentation comments and retention of UserIC.
Comment Actions Thanks Ayal! I'll add the line before committing. Are you ok for the latest iteration to go in? Comment Actions Yes, I'm ok. Would have preferred the separate if (MaybeVF) { VF=..; IC=..; } and if (!MaybeVF && UserIC >0) { InterleaveCount = false; ... } else if ... version, but leave it for you to decide.
|
This UserIC = 1 is now redundant, right?
Thanks!