[clang] [clang][CodeGen] Fix metadata when vectorization is disabled by pragma (PR #135163)

[Ryotaro Kasuga via cfe-commits]

================
@@ -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