add the -mrecip driver flag and process its options

[spatel]

Summary

This is the front-end counterpart to D8982.

The option parsing implementation is based on maintaining compatibility with gcc; gcc documentation for this flag:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627

Note that PowerPC could have its own -mrecip options if further compatibility is desired:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289

With this flag in place, customers will have fine-grain control over reciprocal estimate codegen, so we may choose to align with gcc's optimization behavior for that. Eg, LLVM could generate reciprocal square root by default when -ffast-math is on. This was requested in PR21385 ( https://llvm.org/bugs/show_bug.cgi?id=21385 ).

[hfinkel]

lib/Driver/Tools.cpp

1581 ↗

(On Diff #23644)

As I commented in D8982, I'd like to see options for these added to TargetOptions.h, and then we can handle these in a uniform way across targets. Also, these should default to being on when -ffast-math is enabled, but we can override the defaults with these options.

[spatel]

Patch updated to treat -mrecip as a target-independent flag. Clang just does some simple transforms and error-checking on the input strings and passes them through to the backend. The backend is responsible for further processing and target-specific default settings.

[spatel]

Forgot to mention: as noted in the LLVM patch, this is a superset of gcc's PowerPC and x86 options and then some. We can handle float/double, scalar/vector, and div/sqrt independently and also specify the number of refinement steps per operation type.

[spatel]

Ping.

[spatel]

Ping * 2.

[hfinkel]

lib/Driver/Tools.cpp

1633 ↗

(On Diff #23816)

You should either accept duplicates, or provide a specific error on the duplicated keys. Don't just complain about the number, that's not informative.

1662 ↗

(On Diff #23816)

Why can these be negative?

[spatel]

lib/Driver/Tools.cpp

1662 ↗

(On Diff #23816)

'IsNegative' may just be a poor name choice. I followed the lead of similar code in this file and copied that name.

The '-' prefix on an option means "disable this type of reciprocal".

Please let me know if I've misunderstood your question.

[hfinkel]

lib/Driver/Tools.cpp

1662 ↗

(On Diff #23816)

You did not misunderstand, but I agree, the naming is poor. Let's not replicate it. How about naming it IsDisabled?

[spatel]

lib/Driver/Tools.cpp

1662 ↗

(On Diff #23816)

Yep - that's better. Will fix.

[spatel]

Patch updated:

1. Changed to error out on duplicate argument settings to the -mrecip option; eg: -mrecip=divf,divf
2. Improved variable names
3. Changed refinement step token to ':' (this just looks better than '.' IMO)
4. Fixed logic bug when parsing optional refinement step arg; was allowing correct prefix with bogus suffix ('divffoo') to get through

[hfinkel]

I apologize for not looking at this earlier, but the syntax you're accepting is subtly different from GCC's syntax, and I think that we should try to accept a superset of gcc's syntax (not something subtly different).

GCC, to combine the x86 and PPC options, accepts the keys all, default, div (for both divf and divd), divf, divd, rsqrt (for both rsqrtf and rsqrtd), rsqrtf, rsqrtd, and then these same things with the 'vec-' prefix. '!' is used as the prefix to indicate disabling (not '-' as you have here).

I'm fine with the :<n> syntax extension, but I'd rather use GCC's syntax here as a base for compatibility.

[spatel]

In D8989#173790, @hfinkel wrote:

GCC, to combine the x86 and PPC options, accepts the keys all, default, div (for both divf and divd), divf, divd, rsqrt (for both rsqrtf and rsqrtd), rsqrtf, rsqrtd, and then these same things with the 'vec-' prefix. '!' is used as the prefix to indicate disabling (not '-' as you have here).

I'm fine with the :<n> syntax extension, but I'd rather use GCC's syntax here as a base for compatibility.

Ok - I missed the f/d shortcut. I wasn't sure if compatibility with GCC (the '!') trumped the existing enable/disable (+/-) syntax that we use for target features. Let me know if we should keep the +/- for the llc command-line or switch that to ! as well.

[hfinkel]

In D8989#173894, @spatel wrote:

In D8989#173790, @hfinkel wrote:

GCC, to combine the x86 and PPC options, accepts the keys all, default, div (for both divf and divd), divf, divd, rsqrt (for both rsqrtf and rsqrtd), rsqrtf, rsqrtd, and then these same things with the 'vec-' prefix. '!' is used as the prefix to indicate disabling (not '-' as you have here).

I'm fine with the :<n> syntax extension, but I'd rather use GCC's syntax here as a base for compatibility.

Ok - I missed the f/d shortcut. I wasn't sure if compatibility with GCC (the '!') trumped the existing enable/disable (+/-) syntax that we use for target features. Let me know if we should keep the +/- for the llc command-line or switch that to ! as well.

I'd rather you keep the llc syntax the same.

[hfinkel]

In D8989#173899, @hfinkel wrote:

In D8989#173894, @spatel wrote:

In D8989#173790, @hfinkel wrote:

GCC, to combine the x86 and PPC options, accepts the keys all, default, div (for both divf and divd), divf, divd, rsqrt (for both rsqrtf and rsqrtd), rsqrtf, rsqrtd, and then these same things with the 'vec-' prefix. '!' is used as the prefix to indicate disabling (not '-' as you have here).

I'm fine with the :<n> syntax extension, but I'd rather use GCC's syntax here as a base for compatibility.

Ok - I missed the f/d shortcut. I wasn't sure if compatibility with GCC (the '!') trumped the existing enable/disable (+/-) syntax that we use for target features. Let me know if we should keep the +/- for the llc command-line or switch that to ! as well.

I'd rather you keep the llc syntax the same.

I realize that's ambiguous. I'd rather the llc syntax match the Clang syntax.

[spatel]

In D8989#173900, @hfinkel wrote:

'!' is used as the prefix to indicate disabling (not '-' as you have here).

Hmm...how does this ever work as advertised?

$ gcc -O2 -ffast-math -mrecip=!sqrt recip.c 
bash: !sqrt: event not found

[hfinkel]

• Original Message -----

From: "Sanjay Patel" <[e-mail]>
To: [e-mail], "Andrea DiBiagio" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Sent: Sunday, May 17, 2015 10:46:22 AM
Subject: Re: [PATCH] add the -mrecip driver flag and process its options

In http://reviews.llvm.org/D8989#173900, @hfinkel wrote:

'!' is used as the prefix to indicate disabling (not '-' as you
have here).

Hmm...how does this ever work as advertised?

$ gcc -O2 -ffast-math -mrecip=!sqrt recip.c
bash: !sqrt: event not found

You need quotes.

-Hal

http://reviews.llvm.org/D8989

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/

[spatel]

In D8989#173974, @hfinkel wrote:

'!' is used as the prefix to indicate disabling (not '-' as you
have here).

Hmm...how does this ever work as advertised?

$ gcc -O2 -ffast-math -mrecip=!sqrt recip.c
bash: !sqrt: event not found

You need quotes.

Right; I'm just questioning whether it's worth following gcc on this interface that requires quotes/escapes in common shells when we have an existing syntax that works without it.

[hfinkel]

In D8989#173978, @spatel wrote:

In D8989#173974, @hfinkel wrote:

'!' is used as the prefix to indicate disabling (not '-' as you
have here).

Hmm...how does this ever work as advertised?

$ gcc -O2 -ffast-math -mrecip=!sqrt recip.c
bash: !sqrt: event not found

You need quotes.

Right; I'm just questioning whether it's worth following gcc on this interface that requires quotes/escapes in common shells when we have an existing syntax that works without it.

Yes, it is worth it. There is no reason to force users to remember which compiler uses which minor syntactic differences. Users end up quoting lots of stuff, and turning off these reciprocal estimates in modes where they are otherwise on is likely to be rare, so I'm not particularly bothered by the quoting.

That having been said, I'm not enamored with GCC's syntax, plus, as you know, what GCC accepts is actually different depending on the target (x86 vs. PPC, etc.) I think we should either accept this logicak superset with the same syntax as GCC, or just break with GCC completely and use a different option name (maybe -mrecip-est=..., or something like that, which I think is clearer anyway).

[spatel]

In D8989#174000, @hfinkel wrote:

Yes, it is worth it. There is no reason to force users to remember which compiler uses which minor syntactic differences. Users end up quoting lots of stuff, and turning off these reciprocal estimates in modes where they are otherwise on is likely to be rare, so I'm not particularly bothered by the quoting.

That having been said, I'm not enamored with GCC's syntax, plus, as you know, what GCC accepts is actually different depending on the target (x86 vs. PPC, etc.) I think we should either accept this logicak superset with the same syntax as GCC, or just break with GCC completely and use a different option name (maybe -mrecip-est=..., or something like that, which I think is clearer anyway).

Thanks for the explanation, Hal. I'm not sure which is the greater inconvenience for users (incompatiblity or hostile syntax). Given that we've come this far without supporting -mrecip at all, I agree that it's not worth worrying about too much.

I've gone ahead with the '!' syntax here and in D8982. If we can find a clear preference from users, I assume we can change the interface before this makes it into a clang release. I've tried to make the code changes needed for that as obvious and minimal as possible.

[spatel]

Patch updated:

1. Use '!' for disabling; match existing gcc syntax
2. Added ability to specify recip type without precision (float / double)

[hfinkel]

lib/Driver/Tools.cpp

1623 ↗

(On Diff #26017)

Don't name this like a macro.

1646 ↗

(On Diff #26017)

Don't name these like macros.

[spatel]

Patch updated:
Fixed variable names to not look like macros.

[hfinkel]

LGTM (pending the LLVM change obviously).

lib/Driver/Tools.cpp

1635 ↗

(On Diff #26187)

Please add a comment here explaining that this is reasonable because for currently-supported operations on currently-supported architectures, reasonable value here are 0 through 5 or 6 (and 9 is certainly overkill). We can extend this to support larger numbers as necessary in the future.

[spatel]

Patch updated:
Added comment to explain why a single digit is all we need to specify the number of refinement steps for now.

cfe/trunk/include/clang/Basic/TargetOptions.h

public:
   std::string LinkerVersion;
 
   /// \brief The list of target specific features to enable or disable, as written on the command line.
   std::vector<std::string> FeaturesAsWritten;
 
   /// The list of target specific features to enable or disable -- this should
   /// be a list of strings starting with by '+' or '-'.
   std::vector<std::string> Features;
+  
+  std::vector<std::string> Reciprocals;
 };
 
 }  // end namespace clang
 
 #endif

cfe/trunk/include/clang/Driver/Options.td

 def mrtd : Flag<["-"], "mrtd">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Make StdCall calling convention the default">;
 def msmall_data_threshold_EQ : Joined <["-"], "msmall-data-threshold=">, Group<m_Group>;
 def msoft_float : Flag<["-"], "msoft-float">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Use software floating point">;
 def mno_implicit_float : Flag<["-"], "mno-implicit-float">, Group<m_Group>,
   HelpText<"Don't generate implicit floating point instructions">;
 def mimplicit_float : Flag<["-"], "mimplicit-float">, Group<m_Group>;
+def mrecip : Flag<["-"], "mrecip">, Group<m_Group>;
+def mrecip_EQ : CommaJoined<["-"], "mrecip=">, Group<m_Group>, Flags<[CC1Option]>;
 def msse2 : Flag<["-"], "msse2">, Group<m_x86_Features_Group>;
 def msse3 : Flag<["-"], "msse3">, Group<m_x86_Features_Group>;
 def msse4a : Flag<["-"], "msse4a">, Group<m_x86_Features_Group>;
 def msse4_1 : Flag<["-"], "msse4.1">, Group<m_x86_Features_Group>;
 def msse4_2 : Flag<["-"], "msse4.2">, Group<m_x86_Features_Group>;
 def msse4 : Flag<["-"], "msse4">, Alias<msse4_2>;
 def msse : Flag<["-"], "msse">, Group<m_x86_Features_Group>;
 def mssse3 : Flag<["-"], "mssse3">, Group<m_x86_Features_Group>;

cfe/trunk/lib/CodeGen/BackendUtil.cpp

TargetMachine *EmitAssemblyHelper::CreateTargetMachine(bool MustCreateTM) {
   switch (CodeGenOpts.OptimizationLevel) {
   default: break;
   case 0: OptLevel = CodeGenOpt::None; break;
   case 3: OptLevel = CodeGenOpt::Aggressive; break;
   }
 
   llvm::TargetOptions Options;
 
+  if (!TargetOpts.Reciprocals.empty())
+    Options.Reciprocals = TargetRecip(TargetOpts.Reciprocals);
+
   Options.ThreadModel =
     llvm::StringSwitch<llvm::ThreadModel::Model>(CodeGenOpts.ThreadModel)
       .Case("posix", llvm::ThreadModel::POSIX)
       .Case("single", llvm::ThreadModel::Single);
 
   if (CodeGenOpts.DisableIntegratedAS)
     Options.DisableIntegratedAS = true;
 

cfe/trunk/lib/Driver/Tools.cpp

static void AddGoldPlugin(const ToolChain &ToolChain, const ArgList &Args,
   // the plugin.
 
   // Handle flags for selecting CPU variants.
   std::string CPU = getCPUName(Args, ToolChain.getTriple());
   if (!CPU.empty())
     CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
 }
 
+/// This is a helper function for validating the optional refinement step
+/// parameter in reciprocal argument strings. Return false if there is an error
+/// parsing the refinement step. Otherwise, return true and set the Position
+/// of the refinement step in the input string.
+static bool getRefinementStep(const StringRef &In, const Driver &D,
+                                const Arg &A, size_t &Position) {
+  const char RefinementStepToken = ':';
+  Position = In.find(RefinementStepToken);
+  if (Position != StringRef::npos) {
+    StringRef Option = A.getOption().getName();
+    StringRef RefStep = In.substr(Position + 1);
+    // Allow exactly one numeric character for the additional refinement
+    // step parameter. This is reasonable for all currently-supported
+    // operations and architectures because we would expect that a larger value
+    // of refinement steps would cause the estimate "optimization" to
+    // under-perform the native operation. Also, if the estimate does not
+    // converge quickly, it probably will not ever converge, so further
+    // refinement steps will not produce a better answer.
+    if (RefStep.size() != 1) {
+      D.Diag(diag::err_drv_invalid_value) << Option << RefStep;
+      return false;
+    }
+    char RefStepChar = RefStep[0];
+    if (RefStepChar < '0' || RefStepChar > '9') {
+      D.Diag(diag::err_drv_invalid_value) << Option << RefStep;
+      return false;
+    }
+  }
+  return true;
+}
+
+/// The -mrecip flag requires processing of many optional parameters.
+static void ParseMRecip(const Driver &D, const ArgList &Args,
+                        ArgStringList &OutStrings) {
+  static const char DisabledPrefixIn = '!';
+  static const char DisabledPrefixOut = '!';
+  static const char EnabledPrefixOut = '\0';
+  StringRef Out = "-mrecip=";
+
+  Arg *A = Args.getLastArg(options::OPT_mrecip, options::OPT_mrecip_EQ);
+  if (!A)
+    return;
+
+  unsigned NumOptions = A->getNumValues();
+  if (NumOptions == 0) {
+    // No option is the same as "all".
+    OutStrings.push_back(Args.MakeArgString(Out + "all"));
+    return;
+  }
+
+  // Pass through "all", "none", or "default" with an optional refinement step.
+  if (NumOptions == 1) {
+    StringRef Val = A->getValue(0);
+    size_t RefStepLoc;
+    if (!getRefinementStep(Val, D, *A, RefStepLoc))
+      return;
+    StringRef ValBase = Val.slice(0, RefStepLoc);
+    if (ValBase == "all" || ValBase == "none" || ValBase == "default") {
+      OutStrings.push_back(Args.MakeArgString(Out + Val));
+      return;
+    }
+  }
+
+  // Each reciprocal type may be enabled or disabled individually.
+  // Check each input value for validity, concatenate them all back together,
+  // and pass through.
+
+  llvm::StringMap<bool> OptionStrings;
+  OptionStrings.insert(std::make_pair("divd",       false));
+  OptionStrings.insert(std::make_pair("divf",       false));
+  OptionStrings.insert(std::make_pair("vec-divd",   false));
+  OptionStrings.insert(std::make_pair("vec-divf",   false));
+  OptionStrings.insert(std::make_pair("sqrtd",      false));
+  OptionStrings.insert(std::make_pair("sqrtf",      false));
+  OptionStrings.insert(std::make_pair("vec-sqrtd",  false));
+  OptionStrings.insert(std::make_pair("vec-sqrtf",  false));
+
+  for (unsigned i = 0; i != NumOptions; ++i) {
+    StringRef Val = A->getValue(i);
+
+    bool IsDisabled = Val[0] == DisabledPrefixIn;
+    // Ignore the disablement token for string matching.
+    if (IsDisabled)
+      Val = Val.substr(1);
+
+    size_t RefStep;
+    if (!getRefinementStep(Val, D, *A, RefStep))
+      return;
+
+    StringRef ValBase = Val.slice(0, RefStep);
+    llvm::StringMap<bool>::iterator OptionIter = OptionStrings.find(ValBase);
+    if (OptionIter == OptionStrings.end()) {
+      // Try again specifying float suffix.
+      OptionIter = OptionStrings.find(ValBase.str() + 'f');
+      if (OptionIter == OptionStrings.end()) {
+        // The input name did not match any known option string.
+        D.Diag(diag::err_drv_unknown_argument) << Val;
+        return;
+      }
+      // The option was specified without a float or double suffix.
+      // Make sure that the double entry was not already specified.
+      // The float entry will be checked below.
+      if (OptionStrings[ValBase.str() + 'd']) {
+        D.Diag(diag::err_drv_invalid_value) << A->getOption().getName() << Val;
+        return;
+      }
+    }
+    
+    if (OptionIter->second == true) {
+      // Duplicate option specified.
+      D.Diag(diag::err_drv_invalid_value) << A->getOption().getName() << Val;
+      return;
+    }
+
+    // Mark the matched option as found. Do not allow duplicate specifiers.
+    OptionIter->second = true;
+
+    // If the precision was not specified, also mark the double entry as found.
+    if (ValBase.back() != 'f' && ValBase.back() != 'd')
+      OptionStrings[ValBase.str() + 'd'] = true;
+
+    // Build the output string.
+    const char *Prefix = IsDisabled ?
+      &DisabledPrefixOut : &EnabledPrefixOut;
+    Out = Args.MakeArgString(Out + Prefix + Val);
+    if (i != NumOptions - 1)
+      Out = Args.MakeArgString(Out + ",");
+  }
+
+  OutStrings.push_back(Args.MakeArgString(Out));
+}
+
 static void getX86TargetFeatures(const Driver &D, const llvm::Triple &Triple,
                                  const ArgList &Args,
                                  std::vector<const char *> &Features) {
   // If -march=native, autodetect the feature list.
   if (const Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
     if (StringRef(A->getValue()) == "native") {
       llvm::StringMap<bool> HostFeatures;
       if (llvm::sys::getHostCPUFeatures(HostFeatures))
if (A->getOption().getID() == options::OPT_ffp_contract) {
           << A->getOption().getName() << Val;
       }
     } else if (A->getOption().matches(options::OPT_ffast_math) ||
                (OFastEnabled && A->getOption().matches(options::OPT_Ofast))) {
       // If fast-math is set then set the fp-contract mode to fast.
       CmdArgs.push_back(Args.MakeArgString("-ffp-contract=fast"));
     }
   }
   
+  ParseMRecip(getToolChain().getDriver(), Args, CmdArgs);
+
   // We separately look for the '-ffast-math' and '-ffinite-math-only' flags,
   // and if we find them, tell the frontend to provide the appropriate
   // preprocessor macros. This is distinct from enabling any optimizations as
   // these options induce language changes which must survive serialization
   // and deserialization, etc.
   if (Arg *A = Args.getLastArg(options::OPT_ffast_math, FastMathAliasOption,
                                options::OPT_fno_fast_math))
       if (!A->getOption().matches(options::OPT_fno_fast_math))

cfe/trunk/lib/Frontend/CompilerInvocation.cpp

 static void ParseTargetArgs(TargetOptions &Opts, ArgList &Args) {
   using namespace options;
   Opts.ABI = Args.getLastArgValue(OPT_target_abi);
   Opts.CPU = Args.getLastArgValue(OPT_target_cpu);
   Opts.FPMath = Args.getLastArgValue(OPT_mfpmath);
   Opts.FeaturesAsWritten = Args.getAllArgValues(OPT_target_feature);
   Opts.LinkerVersion = Args.getLastArgValue(OPT_target_linker_version);
   Opts.Triple = llvm::Triple::normalize(Args.getLastArgValue(OPT_triple));
-
+  Opts.Reciprocals = Args.getAllArgValues(OPT_mrecip_EQ);
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
     Opts.Triple = llvm::sys::getDefaultTargetTriple();
 }
 
 bool CompilerInvocation::CreateFromArgs(CompilerInvocation &Res,
                                         const char *const *ArgBegin,
                                         const char *const *ArgEnd,

cfe/trunk/test/Driver/mrecip.c

+////
+//// Verify that valid options for the -mrecip flag are passed through and invalid options cause an error.
+////
+
+//// If there are no options, convert to 'all'.
+
+// RUN: %clang -### -S %s -mrecip  2>&1 | FileCheck --check-prefix=RECIP0 %s
+// RECIP0: "-mrecip=all"
+
+//// Check options that cover all types.
+
+// RUN: %clang -### -S %s -mrecip=all  2>&1 | FileCheck --check-prefix=RECIP1 %s
+// RECIP1: "-mrecip=all"
+
+// RUN: %clang -### -S %s -mrecip=default  2>&1 | FileCheck --check-prefix=RECIP2 %s
+// RECIP2: "-mrecip=default"
+
+// RUN: %clang -### -S %s -mrecip=none  2>&1 | FileCheck --check-prefix=RECIP3 %s
+// RECIP3: "-mrecip=none"
+
+//// Check options that do not specify float or double.
+
+// RUN: %clang -### -S %s -mrecip=vec-sqrt  2>&1 | FileCheck --check-prefix=RECIP4 %s
+// RECIP4: "-mrecip=vec-sqrt"
+
+// RUN: %clang -### -S %s -mrecip=!div,vec-div  2>&1 | FileCheck --check-prefix=RECIP5 %s
+// RECIP5: "-mrecip=!div,vec-div"
+
+//// Check individual option types.
+
+// RUN: %clang -### -S %s -mrecip=vec-sqrtd  2>&1 | FileCheck --check-prefix=RECIP6 %s
+// RECIP6: "-mrecip=vec-sqrtd"
+
+// RUN: %clang -### -S %s -mrecip=!divf  2>&1 | FileCheck --check-prefix=RECIP7 %s
+// RECIP7: "-mrecip=!divf"
+
+// RUN: %clang -### -S %s -mrecip=divf,sqrtd,vec-divd,vec-sqrtf  2>&1 | FileCheck --check-prefix=RECIP8 %s
+// RECIP8: "-mrecip=divf,sqrtd,vec-divd,vec-sqrtf"
+
+//// Check optional refinement step specifiers.
+
+// RUN: %clang -### -S %s -mrecip=all:1  2>&1 | FileCheck --check-prefix=RECIP9 %s
+// RECIP9: "-mrecip=all:1"
+
+// RUN: %clang -### -S %s -mrecip=sqrtf:3  2>&1 | FileCheck --check-prefix=RECIP10 %s
+// RECIP10: "-mrecip=sqrtf:3"
+
+// RUN: %clang -### -S %s -mrecip=div:5  2>&1 | FileCheck --check-prefix=RECIP11 %s
+// RECIP11: "-mrecip=div:5"
+
+// RUN: %clang -### -S %s -mrecip=divd:1,!sqrtf:2,vec-divf:9,vec-sqrtd:0  2>&1 | FileCheck --check-prefix=RECIP12 %s
+// RECIP12: "-mrecip=divd:1,!sqrtf:2,vec-divf:9,vec-sqrtd:0"
+
+//// Check invalid parameters.
+
+// RUN: %clang -### -S %s -mrecip=bogus  2>&1 | FileCheck --check-prefix=RECIP13 %s
+// RECIP13: error: unknown argument
+
+// RUN: %clang -### -S %s -mrecip=divd:1,divd  2>&1 | FileCheck --check-prefix=RECIP14 %s
+// RECIP14: error: invalid value 
+
+// RUN: %clang -### -S %s -mrecip=sqrt,sqrtf  2>&1 | FileCheck --check-prefix=RECIP15 %s
+// RECIP15: error: invalid value 
+
+// RUN: %clang -### -S %s -mrecip=+default:10  2>&1 | FileCheck --check-prefix=RECIP16 %s
+// RECIP16: error: invalid value 
+
+// RUN: %clang -### -S %s -mrecip=!vec-divd:  2>&1 | FileCheck --check-prefix=RECIP17 %s
+// RECIP17: error: invalid value 
+