This patch begins the process of supporting the vscale_range attribute
for RVV.
Most notably, this patch implements the attribute according to the
minimum and maximum values of VLEN according to specific V extensions
being compiled for. The minimum is taken using the minimum-known VLEN
(i.e., specified through the V or zvl*b extensions) and the maximum is
unconditionally taken as 65536. Both values are then divided by our
"bits per block" value, hardcoded to 64.
The backend can still be given more information about VLEN using the
-riscv-v-vector-bits-min and -riscv-v-vector-bits-max flags. This
means that the API it aims to replace,
TargetTransformInfo::getMaxVScale, may still generate better code with
its better knowledge. Those options override the values found in the
vscale_range attribute.
It is unclear whether we want to move those backend options up into the
frontend, whether we are able to allow the backend to infer all
information from the IR attribute, or whether we even want to do that;
that's a wider discussion.
Should we move RVVBitsPerBlock to RISCVTargetParser.def? Or some other place that can be shared between lllvm/lib/Target/RISCV/ and here?