Rather than maintaining two separate values, a float for the per-lane
cost and a Width for the VF, maintain a single VectorizationFactor which
comprises the two and also removes the need for converting an integer value
to float.
This simplifies the query when asking if one VF is more profitable than
another when we want to extend this for scalable vectors (which may
require additional options to determine if e.g. a scalable VF of the
some cost, is more profitable than a fixed VF of the same cost).
The patch isn't entirely NFC because it also fixes an issue in
selectEpilogueVectorizationFactor, where the cost passed to ProfitableVFs
no longer truncates the floating-point cost from float to unsigned to
then perform the calculation on the truncated cost. It now does
a cost comparison with the correct precision.
Hi Sander, a minor question here: for scalable vectorization do you plan to change the definition of Disabled? Perhaps this may not be needed?
We were considering something like return {ElementCount:getNull(), 0}; so this VectorizationFactor value is effectively not a valid vectorization factor at all. But maybe this is not the intent of Disabled?