According the discuss on D154953, we need to make the LangRef change
before the optimization relied on the new behaviour:
vscale_range implies vscale is a power-of-two value, parse of the attribute to reject values that are not a power-of-two.
Differential D155193
[LangRef] vscale_range implies the vscale is power-of-two Allen on Jul 13 2023, 6:05 AM. Authored by
Details According the discuss on D154953, we need to make the LangRef change vscale_range implies vscale is a power-of-two value, parse of the attribute to reject values that are not a power-of-two.
Diff Detail
Event TimelineComment Actions To provide a bit more context here. We would like to have power of two vscale exposed in a target-independent way, so we can make use of this in places like ValueTracking, just like we currently do the vscale range. Some options that have been discussed are:
Comment Actions The approach taken here seems fine. It gives the optimization opportunities we want now, but leaves open an escape hatch for non-power-of-two widths if some target does end up needing them. (SVE does require power-of-two lengths, but they made that decision very late; there seems to be some room for other architectures to make a different choice.) Comment Actions I've offered some alternate phrasing to consider but am happy to accept the patch on principle. Please give others a chance to comment on your final choice of phrasing before landing the patch.
|
I'd prefer a more unified description. What about: