This is an archive of the discontinued LLVM Phabricator instance.

[LangRef] vscale_range implies the vscale is power-of-two
ClosedPublic

Authored by Allen on Jul 13 2023, 6:05 AM.

Details

Summary

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.

Diff Detail

Event Timeline

Allen created this revision.Jul 13 2023, 6:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 13 2023, 6:05 AM
Allen requested review of this revision.Jul 13 2023, 6:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 13 2023, 6:05 AM
nikic added a reviewer: efriedma.EditedJul 13 2023, 2:00 PM

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:

  • Remove support for non-power-of-two vscales entirely. (This is my personal preference, but this is hard to undo if it turns out someone does need them.)
  • Add an extra attribute vscale_pow2, or a data layout property.
  • Make vscale_range imply power-of-two vscale, as a compromise solution (what this patch does). This would be relatively easy to turn into one of the two above at a later point.
llvm/docs/BitCodeFormat.rst
1095 ↗(On Diff #539985)

This change does not affect the bitcode format, no need to modify this file.

llvm/docs/LangRef.rst
2340

This just restricts the min and max. You need to specify that vscale itself is a power of two if the attribute is specified.

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.)

Matt added a subscriber: Matt.Jul 13 2023, 2:35 PM
Allen updated this revision to Diff 540243.Jul 13 2023, 6:03 PM

Address comments

Allen marked 2 inline comments as done.Jul 13 2023, 6:05 PM
Allen added inline comments.
llvm/docs/BitCodeFormat.rst
1095 ↗(On Diff #539985)

reverted, thanks

llvm/docs/LangRef.rst
2340

Apply your comment, thanks

paulwalker-arm accepted this revision.Jul 14 2023, 4:48 AM

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.

llvm/docs/LangRef.rst
2335–2339

I'd prefer a more unified description. What about:

This function attribute indicates `vscale` is a power-of-two within a specified range. `min` must be a power-of-two that is greater than 0. When specified, `max` must be a power-of-two greater-than-or-equal to `min` or 0 to signify an unbounded maximum. The syntax `vscale_range(<val>)` can be used to set both `min` and `max` to the same value. Functions that don't include this attribute make no assumptions about the value of `vscale`.
This revision is now accepted and ready to land.Jul 14 2023, 4:48 AM
Allen updated this revision to Diff 540366.Jul 14 2023, 5:12 AM
Allen marked 2 inline comments as done.

Thanks, apply your comment , and I'll wait a couple days before landing this patch.

nikic accepted this revision.Jul 14 2023, 5:27 AM

LGTM

This revision was landed with ongoing or failed builds.Jul 14 2023, 6:18 PM
This revision was automatically updated to reflect the committed changes.