[llvm] Minor post-commit review changes for #130988 (NFC) (PR #156895)

[Frederik Harwath via llvm-commits]

================
@@ -719,12 +719,12 @@ FUNCTION_PASS_WITH_PARAMS(
     },
     parseBoundsCheckingOptions,
     "trap;rt;rt-abort;min-rt;min-rt-abort;merge;guard=N")
-    FUNCTION_PASS_WITH_PARAMS(
+FUNCTION_PASS_WITH_PARAMS(
     "expand-fp", "ExpandFpPass",
     [TM = TM](CodeGenOptLevel OL) {
       return ExpandFpPass(TM, OL);
     },
-    parseExpandFpOptions, "opt-level")
+    parseExpandFpOptions, "opt-level=N")
----------------
frederik-h wrote:

> > This opt-level argument is strange. What do other passes do for the opt level argument? This is only used in a binary way in the pass so does it really need the level?
> 
> You are right, it is common to use the optimization level directly. That is, you would write `expand-fp<O0>` instead of `expand-fp<opt-level=0>`. Perhaps I was worried about other arguments that we might want to be able to use here, but that would simply work as in, e.g. `loop-unroll<partial;O2>`. I will change the argument parsing to use the same format.

See PR #157408 which changes `opt-level=0` to `O0` etc.


https://github.com/llvm/llvm-project/pull/156895