[LV] Make scalable-vectorization not work if there is a specified scalable pragma hint.

[fakepaper56]

Summary

For issue github.com/llvm/llvm-project/issues/56462, the patch make
ForceScalableVectorization have lower priority than pragma, in other word,
ForceScalableVectorization will only work if there is no specified scalable
pragma hint.

After the patch, we could disable vectorization with -scalable-vectorization=on
by pragma vectorize_width(1, fixed).

[sdesmalen]

After this change, the behaviour no longer matches the behaviour described above on lines 118-120:

// If the metadata doesn't explicitly specify whether to enable scalable
// vectorization, then decide based on the following criteria (increasing
// level of priority):
//  - Target default
//  - Metadata width
//  - Force option (always overrides)

because it no longer overrides the loop hint if one is specified.

[fakepaper56]

In D129473#3641972, @sdesmalen wrote:

After this change, the behaviour no longer matches the behaviour described above on lines 118-120:

// If the metadata doesn't explicitly specify whether to enable scalable
// vectorization, then decide based on the following criteria (increasing
// level of priority):
//  - Target default
//  - Metadata width
//  - Force option (always overrides)

because it no longer overrides the loop hint if one is specified.

Sorry, I don't understand your idea. I think the change not only reserves the priority of the three cases but also realize the predicate "If the metadata doesn't explicitly specify whether to enable scalable".

[sdesmalen]

When compiling the following example with your patch applied and passing -mllvm -scalable-vectorization=off, the loop still vectorizes using scalable vectors:

void foo(int * restrict dst, int * src, int N) {
  #pragma clang loop vectorize_width(4, scalable)
  for (int i=0; i<N; ++i)
    dst[i] = src[i] + 42;
}

The idea behind giving this flag highest priority was to give users the ability to blanket disable scalable VFs in case they find any issues, since they're still a relatively new feature compared to fixed-width vectors. e.g. https://godbolt.org/z/fE8Exjos9.

I guess it's not very common for users to write these pragmas and perhaps we want to change it such that the pragma has priority over the (force) flag. If so, it would mean changing the comment on the lines above.
@paulwalker-arm, @reames, @fhahn any thoughts/opinions on this?

@fakepaper56 Could you add a test case guarding the functional change in this patch?

[fakepaper56]

Add test case and remove some dead code.

[fakepaper56]

Thank @sdesmalen telling the origin intent of -scalable-vectorization=. I haven't think that before.

llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp

if (TTI)
       Scalable.Value = TTI->enableScalableVectorization() ? SK_PreferScalable
                                                           : SK_FixedWidthOnly;
 
     if (Width.Value)
       // If the width is set, but the metadata says nothing about the scalable
       // property, then assume it concerns only a fixed-width UserVF.
       // If width is not set, the flag takes precedence.
       Scalable.Value = SK_FixedWidthOnly;
-  }
 
-  // If the flag is set to force any use of scalable vectors, override the loop
-  // hints.
+    // If the flag is set to force any use of scalable vectors, override the
+    // loop hints.
     if (ForceScalableVectorization.getValue() !=
         LoopVectorizeHints::SK_Unspecified)
       Scalable.Value = ForceScalableVectorization.getValue();
+  }
 
   // Scalable vectorization is disabled if no preference is specified.
   if ((LoopVectorizeHints::ScalableForceKind)Scalable.Value == SK_Unspecified)
     Scalable.Value = SK_FixedWidthOnly;
 
   if (IsVectorized.Value != 1)
     // If the vectorization width and interleaving count are both 1 then
     // consider the loop to have been already vectorized because there's