================
@@ -5237,8 +5237,8 @@ width/count of the set of target architectures supported
by your application.
...
}
-Specifying a width/count of 1 disables the optimization, and is equivalent to
-``vectorize(disable)`` or ``interleave(disable)``.
----------------
kasuga-fj wrote:
I've been thinking about this for a while, and now I think it triggers
ambiguity in the pragma interpretation if we consider `vectorize(disable)` and
`vectorize_width(1)` to be equivalent.`vectorize(disable)
vectorize_width(scalable)` is an example of such a case. The
[document](https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations)
says:
> Pragmas setting transformation options imply the transformation is enabled,
> as if it was enabled via the corresponding transformation pragma (e.g.
> `vectorize(enable)`). If the transformation is disabled (e.g.
> `vectorize(disable)`), that takes precedence over transformations option
> pragmas implying that transformation.
In this perspective, I think it is correct to ignore
`vectorize_width(scalable)` and disable vectorization, since it falls under
"transformations option pragmas implying that transformation". However, it also
makes sense to consider `vectorize(disable) vectorize_width(scalable)` as
`vectorize_width(1, scalable)` if `vectorize(disable)` is equivalent to
`vectorize_width(1)`. In this case, we should process vectorization, as
mentioned in the [previous review
comment](https://github.com/llvm/llvm-project/pull/135163#discussion_r2037236948).
I think we should stop interpreting `vectorize(disable)` and
`vectorize_width(1)` as equivalent, but it might break some compatibilities.
So, what do you think?
https://github.com/llvm/llvm-project/pull/135163
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
