[all-commits] [llvm/llvm-project] 720328: [LangRef] vscale_range implies the vscale is power...

[Allen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7203286329defc7976c719d8750712c0d5de9c31
      https://github.com/llvm/llvm-project/commit/7203286329defc7976c719d8750712c0d5de9c31
  Author: Zhongyunde <zhongyunde at huawei.com>
  Date:   2023-07-15 (Sat, 15 Jul 2023)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/IR/Verifier.cpp
    M llvm/test/Transforms/InstCombine/icmp-vscale.ll
    M llvm/test/Transforms/InstCombine/vscale_sext_and_zext.ll
    M llvm/test/Transforms/InstCombine/vscale_trunc.ll
    M llvm/test/Verifier/vscale_range.ll

  Log Message:
  -----------
  [LangRef] vscale_range implies the vscale is power-of-two

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.

Thanks nikic for the wonderful summary of discussing on D154953:
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.

Reviewed By: paulwalker-arm, nikic, efriedma
Differential Revision: https://reviews.llvm.org/D155193