https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123225
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #15) > In my opinion, as I mentioned before, costing for uncounted loops should be > based on the single iteration cost of the vector loop vs the scalar, and > this value for profitability should be used to version the loop. > > What we want is a runtime threshold for profitability, similar to how we > version normal loops. This feels more correct to me and it would allow > targets to adjust this scale. This is similar to what we do today already > for known iters loops. > > And vectorizeration statically rejected when the vector costs / VF > scalar > costs. ie the vector costs will never beat scalar per iteration. But you cannot compute a runtime threshold for uncounted loops (or also very much early-break ones where we ignore the possibility of breaking early). What you are left with is profile-data (loop will very likely at least run N times), hand-waving (loops will usually run at least N times), or hard checking (even when the loop immediately exits the vector version isn't worse). With early-break (and uncounted loop) re-executing the last N iterations in the epilog that hard checking can never work out.
