7203286329
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
14 lines
452 B
LLVM
14 lines
452 B
LLVM
; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
|
|
|
|
; CHECK: 'vscale_range' minimum must be greater than 0
|
|
declare ptr @a(ptr) vscale_range(0, 1)
|
|
|
|
; CHECK: 'vscale_range' minimum cannot be greater than maximum
|
|
declare ptr @b(ptr) vscale_range(8, 1)
|
|
|
|
; CHECK: 'vscale_range' minimum must be power-of-two value
|
|
declare ptr @c(ptr) vscale_range(3, 16)
|
|
|
|
; CHECK: 'vscale_range' maximum must be power-of-two value
|
|
declare ptr @d(ptr) vscale_range(2, 5)
|