[WebAssembly] Add -fwasm-exceptions for wasm EH

[aheejin]

Summary

This adds -fwasm-exceptions (in similar fashion with
-fdwarf-exceptions or -fsjlj-exceptions) that turns on everything
with wasm exception handling from the frontend to the backend.

We currently have -mexception-handling in clang frontend, but this is
only about the architecture capability and does not turn on other
necessary options such as the exception model in the backend. (This can
be turned on with llc -exception-model=wasm, but llc is not invoked
separately as a command line tool, so this option has to be transferred
from clang.)

Turning on -fwasm-exceptions in clang also turns on
-mexception-handling if not specified, and will error out if
-mno-exception-handling is specified.

[aheejin]

• Remove a blank line

[tlively]

Is there a plan to turn this on by default at some point, or will users always have to opt-in to using exceptions? Also, would it make sense to automatically turn this feature on if the user instead supplies -mexception-handling to turn on the target feature?

[sbc100]

I don't really see why we can't just have the existing -mexception-handling take on this new meaning?

[sbc100]

Is there some reason why clang can't pass the -exception-model=wasm flag programatically to llc when -mmexception-handling is set?

[aheejin]

@tlively @sbc100 What I wanted was to make -fwasm-exceptions as something like -pthreads, which serves as the only flag that needs to be turned on and turns on all other necessary flags, such as +matomics, +mbulk-memory, and --shared-memory. I think all those architectural flags starting with -m can be someday all turned on, when all our existing proposals become the new MVP, and I still want to give users an option to opt out of threads of exception handling at that point. And it also makes sense to have a LangOption of WasmExceptions given that there are LangOptions for all other exception models. I think this covers most of the questions above.

@tlively

Is there a plan to turn this on by default at some point, or will users always have to opt-in to using exceptions?

I'm planning to create an emscripten option, something like -s EXCEPTION_HANDLING=1, to turn this option on. Maybe at some point, when we don't use emscripten exception anymore and all wasm platforms (wasi and emscripten and what not) use the new exception proposal, we can consider turning this on by default. Until then I incline not to.

[sbc100]

But why not make -mexception-handling be the option that enabled everything? I mean -mexception-handling is a flag we have today.. if you add -fwasm-exceptions what does -mexception-handling meaning? Is it still useful?

[dschuff]

If this is to be like -fdwarf-exceptions I assume the idea is that eventually it will default on when targeting wasm, and become one of those flags that most users never set. In that case it really just selects the default exception model, and thus it should be compatible with -fno-exceptions just as -fdwarf-exceptions is.
Also -fno-exceptions doesn't really mean "no exceptions whatsoever" because IIRC if you call something that the compiler isn't sure never throws, it generates an implicit catch-all that calls std::terminate. So how it does that would still be affected by the exception model. (and whatever downstream invoke-removing pass or postprocessing tool might care).

[aheejin]

In D67208#1659941, @sbc100 wrote:

But why not make -mexception-handling be the option that enabled everything? I mean -mexception-handling is a flag we have today.. if you add -fwasm-exceptions what does -mexception-handling meaning? Is it still useful?

As I said above, I'm not sure making architecture flags control everything is a good idea. I view those flags as very low-level flags whose only job is exactly turn on those architecture features (Others may view them differently though). Likewise, currently setting --pthreads controls other features, but setting -matomics or -mbulk-memory does not control other features.

[aheejin]

In D67208#1659972, @dschuff wrote:

If this is to be like -fdwarf-exceptions I assume the idea is that eventually it will default on when targeting wasm, and become one of those flags that most users never set. In that case it really just selects the default exception model, and thus it should be compatible with -fno-exceptions just as -fdwarf-exceptions is.\

-fwasm-exceptions works fine with -fno-exceptions. That has the same effect as when you specify both -fdwarf-exceptions and -fno-exceptions together; it just lowers invokes to calls. Is that not what you mean? What -fwasm-exceptions is not compatible with is -mno-exception-handling.

Also -fno-exceptions doesn't really mean "no exceptions whatsoever" because IIRC if you call something that the compiler isn't sure never throws, it generates an implicit catch-all that calls std::terminate. So how it does that would still be affected by the exception model. (and whatever downstream invoke-removing pass or postprocessing tool might care).

-fno-exceptions does not generate try-catch with calls to std::terminate. The native x86 compiler does not do that either. It just assumes exceptions don't exist. (And you can't use keywords like try, catch, or throw with -fno-exceptions.) What you described is when we use noexcept on the function declaration but the function calls another function that can throw, I think.

[sbc100]

Derek, are you saying that -mexception-handling is somehow related to -fno-exceptions. What is the relationship? I wasn't aware this change was related to -fno-exceptions.

-pthreads enabling -matomics and -mbulk-memorymake some sense because each of those low level flags might make sense on its own. But if -fwasm-exceptions only going to enable -mexception-handling then I'm not sure I see the point in adding it. Or is there something else it will enable? Also, we didn't add -pthread, it was pre-existing we we didn't need to justify adding it but rather make it work.

Sorry, I'm not necessarily against this change but I want to avoid adding flags unless there is a clear need.

[dschuff]

Oh, you're right, I'm conflating -mexception-handling with -fexceptions. And also -fno-exceptions with noexcept. So... just forget I was here

[aheejin]

This comment was removed by aheejin.

[aheejin]

In D67208#1660041, @sbc100 wrote:

-pthreads enabling -matomics and -mbulk-memorymake some sense because each of those low level flags might make sense on its own. But if -fwasm-exceptions only going to enable -mexception-handling then I'm not sure I see the point in adding it. Or is there something else it will enable?

I think I didn't provide enough motives; let me explain this over again.
tl;dr: I think -fwasm-exceptionsis necessary. Something we should decide is whether we should make -mexception-handling turn it on automatically.

1. Why we need LangOptions::WasmExceptions

What we need to additionally set besides -mattr=+exception-handling in the backend is -exception-model=wasm, which sets the exception model. (We need to set this programmatically. I used llc options just for illustration) This part corresponds to this code in clang/lib/CodeGen/BackendUtil.cpp above.

if (LangOpts.SjLjExceptions)
  Options.ExceptionModel = llvm::ExceptionHandling::SjLj;
if (LangOpts.SEHExceptions)
  Options.ExceptionModel = llvm::ExceptionHandling::WinEH;
if (LangOpts.DWARFExceptions)
  Options.ExceptionModel = llvm::ExceptionHandling::DwarfCFI;
if (LangOpts.WasmExceptions)
  Options.ExceptionModel = llvm::ExceptionHandling::Wasm;

If we don't have LangOption::WasmExceptions, we would need to invoke target features to set this option, which is not very clean and inconsistent with other exception models.

Also, because we didn't have LangOptions::WasmExceptions, the current code for selecting personality function is not very clear. This CL fixes this too.

2. Why we need -fwasm-exceptions

-fwasm-exceptions is the means to set LangOptions::WasmExceptions. Please see the code for clang/lib/Frontend/CompilerInvocation.cpp in this CL.

Arg *A = Args.getLastArg(
    options::OPT_fsjlj_exceptions, options::OPT_fseh_exceptions,
    options::OPT_fdwarf_exceptions, options::OPT_fwasm_exceptions);
if (A) {
  ...
  Opts.SjLjExceptions = Opt.matches(options::OPT_fsjlj_exceptions);
  Opts.SEHExceptions = Opt.matches(options::OPT_fseh_exceptions);
  Opts.DWARFExceptions = Opt.matches(options::OPT_fdwarf_exceptions);
  Opts.WasmExceptions = Opt.matches(options::OPT_fwasm_exceptions);
}

If we don't have options::OPT_fwasm_exceptions there, the code to determine whether we have to set Opts.WasmExceptions will be not very clean and inconsistent with other model options.
(Here this Opts.WasmExceptions will be the same as LangOpts.WasmExceptions in clang/lib/CodeGen/BackendUtil.cpp above.)

3. Why I think choosing -fwasm-exceptions, not -mexception-handling, as the controlling option, is better

Given that we need -fwasm-exceptions anyway (according to 1 and 2 above), I think -fwasm-exceptions sets -mexception-handling makes more sense than the other way around. Also, as I said above, I'm not sure if using architectural flags to control features is a good idea. They are pretty low-level, and they only exist because wasm features are developed one by one; if we were able to put everything into MVP they wouldn't exist. Wouldn't we someday turn on all these architectural flags on by default? And it's possible that we want to use the current emscripten-based exception even if we have all architectural features turned on.

[tlively]

Thanks for the clarification. It makes sense to me that -mexception-handling only enables the architectural feature and a separate flag enables the behavior change. This is indeed consistent with how -pthread works.

What happens when users have exceptions in their code but don't pass -fwasm-exceptions? Do they get the old SJLJ emulated exception handling?

[aheejin]

In D67208#1661694, @tlively wrote:

What happens when users have exceptions in their code but don't pass Do they get the old SJLJ emulated exception handling?

The current emscripten EH is enabled by clang -mllvm -enable-emscripten-cxx-exceptions, which is not a clang flag (it's passed by -mllvm, so it is for the LLVM). The reason it is not a clang flag is emscripten EH does not need any action in clang. This flag is set when you pass 0 or 2 to -s DISABLE_EXCEPTION_CATCHING= emscripten flag.

If users use exceptions but don't pass -fwasm-exceptions, if they pass -mllvm -enable-emscripten-cxx-exceptions instead, emscripten EH will be used. If they pass neither, neither EH will be used and all invokes will be lowered to calls.

Having said that, -fwasm-exceptions and -mllvm -enable-emscripten-cxx-exceptions are not compatible. If we can check this that'd be better. I'll check.

[aheejin]

• Error out when -fwasm-exceptions is specified with -mllvm -enable-emscripten-cxx-exceptions

clang/include/clang/Basic/LangOptions.def

 LANGOPT(AltiVec           , 1, 0, "AltiVec-style vector initializers")
 LANGOPT(ZVector           , 1, 0, "System z vector extensions")
 LANGOPT(Exceptions        , 1, 0, "exception handling")
 LANGOPT(ObjCExceptions    , 1, 0, "Objective-C exceptions")
 LANGOPT(CXXExceptions     , 1, 0, "C++ exceptions")
 LANGOPT(DWARFExceptions   , 1, 0, "dwarf exception handling")
 LANGOPT(SjLjExceptions    , 1, 0, "setjmp-longjump exception handling")
 LANGOPT(SEHExceptions     , 1, 0, "SEH .xdata exception handling")
+LANGOPT(WasmExceptions    , 1, 0, "WebAssembly exception handling")
 LANGOPT(ExternCNoUnwind   , 1, 0, "Assume extern C functions don't unwind")
 LANGOPT(TraditionalCPP    , 1, 0, "traditional CPP emulation")
 LANGOPT(RTTI              , 1, 1, "run-time type information")
 LANGOPT(RTTIData          , 1, 1, "emit run-time type information data")
 LANGOPT(MSBitfields       , 1, 0, "Microsoft-compatible structure layout")
 LANGOPT(Freestanding, 1, 0, "freestanding implementation")
 LANGOPT(NoBuiltin         , 1, 0, "disable builtin functions")
 LANGOPT(NoMathBuiltin     , 1, 0, "disable math builtin functions")

clang/include/clang/Driver/Options.td

 def fexceptions : Flag<["-"], "fexceptions">, Group<f_Group>, Flags<[CC1Option]>,
   HelpText<"Enable support for exception handling">;
 def fdwarf_exceptions : Flag<["-"], "fdwarf-exceptions">, Group<f_Group>,
   Flags<[CC1Option]>, HelpText<"Use DWARF style exceptions">;
 def fsjlj_exceptions : Flag<["-"], "fsjlj-exceptions">, Group<f_Group>,
   Flags<[CC1Option]>, HelpText<"Use SjLj style exceptions">;
 def fseh_exceptions : Flag<["-"], "fseh-exceptions">, Group<f_Group>,
   Flags<[CC1Option]>, HelpText<"Use SEH style exceptions">;
+def fwasm_exceptions : Flag<["-"], "fwasm-exceptions">, Group<f_Group>,
+  Flags<[CC1Option]>, HelpText<"Use WebAssembly style exceptions">;
 def fexcess_precision_EQ : Joined<["-"], "fexcess-precision=">,
     Group<clang_ignored_gcc_optimization_f_Group>;
 def : Flag<["-"], "fexpensive-optimizations">, Group<clang_ignored_gcc_optimization_f_Group>;
 def : Flag<["-"], "fno-expensive-optimizations">, Group<clang_ignored_gcc_optimization_f_Group>;
 def fextdirs_EQ : Joined<["-"], "fextdirs=">, Group<f_Group>;
 def : Flag<["-"], "fdefer-pop">, Group<clang_ignored_gcc_optimization_f_Group>;
 def : Flag<["-"], "fno-defer-pop">, Group<clang_ignored_gcc_optimization_f_Group>;
 def : Flag<["-"], "fextended-identifiers">, Group<clang_ignored_f_Group>;

clang/lib/CodeGen/BackendUtil.cpp

static void initTargetOptions(llvm::TargetOptions &Options,
   Options.EABIVersion = TargetOpts.EABIVersion;
 
   if (LangOpts.SjLjExceptions)
     Options.ExceptionModel = llvm::ExceptionHandling::SjLj;
   if (LangOpts.SEHExceptions)
     Options.ExceptionModel = llvm::ExceptionHandling::WinEH;
   if (LangOpts.DWARFExceptions)
     Options.ExceptionModel = llvm::ExceptionHandling::DwarfCFI;
+  if (LangOpts.WasmExceptions)
+    Options.ExceptionModel = llvm::ExceptionHandling::Wasm;
 
   Options.NoInfsFPMath = CodeGenOpts.NoInfsFPMath;
   Options.NoNaNsFPMath = CodeGenOpts.NoNaNsFPMath;
   Options.NoZerosInBSS = CodeGenOpts.NoZeroInitializedInBSS;
   Options.UnsafeFPMath = CodeGenOpts.UnsafeFPMath;
   Options.StackAlignmentOverride = CodeGenOpts.StackAlignment;
   Options.FunctionSections = CodeGenOpts.FunctionSections;
   Options.DataSections = CodeGenOpts.DataSections;

clang/lib/CodeGen/CGException.cpp

static const EHPersonality &getCXXPersonality(const TargetInfo &Target,
   if (T.isWindowsMSVCEnvironment())
     return EHPersonality::MSVC_CxxFrameHandler3;
   if (L.SjLjExceptions)
     return EHPersonality::GNU_CPlusPlus_SJLJ;
   if (L.DWARFExceptions)
     return EHPersonality::GNU_CPlusPlus;
   if (L.SEHExceptions)
     return EHPersonality::GNU_CPlusPlus_SEH;
-  // Wasm EH is a non-MVP feature for now.
-  if (Target.hasFeature("exception-handling") &&
-      (T.getArch() == llvm::Triple::wasm32 ||
-       T.getArch() == llvm::Triple::wasm64))
+  if (L.WasmExceptions)
     return EHPersonality::GNU_Wasm_CPlusPlus;
   return EHPersonality::GNU_CPlusPlus;
 }
 
 /// Determines the personality function to use when both C++
 /// and Objective-C exceptions are being caught.
 static const EHPersonality &getObjCXXPersonality(const TargetInfo &Target,
                                                  const LangOptions &L) {

clang/lib/Driver/ToolChains/Clang.cpp

if (Args.hasFlag(options::OPT_fapplication_extension,
                    options::OPT_fno_application_extension, false))
     CmdArgs.push_back("-fapplication-extension");
 
   // Handle GCC-style exception args.
   if (!C.getDriver().IsCLMode())
     addExceptionArgs(Args, InputType, TC, KernelOrKext, Runtime, CmdArgs);
 
   // Handle exception personalities
-  Arg *A = Args.getLastArg(options::OPT_fsjlj_exceptions,
-                           options::OPT_fseh_exceptions,
-                           options::OPT_fdwarf_exceptions);
+  Arg *A = Args.getLastArg(
+      options::OPT_fsjlj_exceptions, options::OPT_fseh_exceptions,
+      options::OPT_fdwarf_exceptions, options::OPT_fwasm_exceptions);
   if (A) {
     const Option &Opt = A->getOption();
     if (Opt.matches(options::OPT_fsjlj_exceptions))
       CmdArgs.push_back("-fsjlj-exceptions");
     if (Opt.matches(options::OPT_fseh_exceptions))
       CmdArgs.push_back("-fseh-exceptions");
     if (Opt.matches(options::OPT_fdwarf_exceptions))
       CmdArgs.push_back("-fdwarf-exceptions");
+    if (Opt.matches(options::OPT_fwasm_exceptions))
+      CmdArgs.push_back("-fwasm-exceptions");
   } else {
     switch (TC.GetExceptionModel(Args)) {
     default:
       break;
     case llvm::ExceptionHandling::DwarfCFI:
       CmdArgs.push_back("-fdwarf-exceptions");
       break;
     case llvm::ExceptionHandling::SjLj:

clang/lib/Driver/ToolChains/WebAssembly.cpp

if (DriverArgs.hasFlag(options::OPT_mno_mutable_globals,
           << "-mno-mutable-globals";
     CC1Args.push_back("-target-feature");
     CC1Args.push_back("+atomics");
     CC1Args.push_back("-target-feature");
     CC1Args.push_back("+bulk-memory");
     CC1Args.push_back("-target-feature");
     CC1Args.push_back("+mutable-globals");
   }
+
+  // '-fwasm-exceptions' implies exception-handling
+  if (DriverArgs.getLastArg(options::OPT_fwasm_exceptions)) {
+    if (DriverArgs.hasFlag(options::OPT_mno_exception_handing,
+                           options::OPT_mexception_handing, false))
+      getDriver().Diag(diag::err_drv_argument_not_allowed_with)
+          << "-fwasm-exceptions"
+          << "-mno-exception-handling";
+    CC1Args.push_back("-target-feature");
+    CC1Args.push_back("+exception-handling");
+  }
 }
 
 ToolChain::RuntimeLibType WebAssembly::GetDefaultRuntimeLibType() const {
   return ToolChain::RLT_CompilerRT;
 }
 
 ToolChain::CXXStdlibType
 WebAssembly::GetCXXStdlibType(const ArgList &Args) const {

clang/lib/Frontend/CompilerInvocation.cpp

Opts.FixedPoint =
       !Opts.CPlusPlus;
   Opts.PaddingOnUnsignedFixedPoint =
       Args.hasFlag(OPT_fpadding_on_unsigned_fixed_point,
                    OPT_fno_padding_on_unsigned_fixed_point,
                    /*Default=*/false) &&
       Opts.FixedPoint;
 
   // Handle exception personalities
-  Arg *A = Args.getLastArg(options::OPT_fsjlj_exceptions,
-                           options::OPT_fseh_exceptions,
-                           options::OPT_fdwarf_exceptions);
+  Arg *A = Args.getLastArg(
+      options::OPT_fsjlj_exceptions, options::OPT_fseh_exceptions,
+      options::OPT_fdwarf_exceptions, options::OPT_fwasm_exceptions);
   if (A) {
     const Option &Opt = A->getOption();
     llvm::Triple T(TargetOpts.Triple);
     if (T.isWindowsMSVCEnvironment())
       Diags.Report(diag::err_fe_invalid_exception_model)
           << Opt.getName() << T.str();
 
     Opts.SjLjExceptions = Opt.matches(options::OPT_fsjlj_exceptions);
     Opts.SEHExceptions = Opt.matches(options::OPT_fseh_exceptions);
     Opts.DWARFExceptions = Opt.matches(options::OPT_fdwarf_exceptions);
+    Opts.WasmExceptions = Opt.matches(options::OPT_fwasm_exceptions);
   }
 
   Opts.ExternCNoUnwind = Args.hasArg(OPT_fexternc_nounwind);
   Opts.TraditionalCPP = Args.hasArg(OPT_traditional_cpp);
 
   Opts.RTTI = Opts.CPlusPlus && !Args.hasArg(OPT_fno_rtti);
   Opts.RTTIData = Opts.RTTI && !Args.hasArg(OPT_fno_rtti_data);
   Opts.Blocks = Args.hasArg(OPT_fblocks) || (Opts.OpenCL

clang/test/CodeGenCXX/wasm-eh.cpp

-// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
-// RUN: %clang_cc1 %s -triple wasm64-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
+// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -fwasm-exceptions -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
+// RUN: %clang_cc1 %s -triple wasm64-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -fwasm-exceptions -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
+// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -fwasm-exceptions -target-feature +exception-handling -S -o - -std=c++11 | FileCheck %s --check-prefix=ASSEMBLY
 
 void may_throw();
 void dont_throw() noexcept;
 
 struct Cleanup {
   ~Cleanup() { dont_throw(); }
 };
 

 
 // CHECK:   %[[CLEANUPPAD0:.*]] = cleanuppad within %[[CATCHPAD1]] []
 // CHECK:   cleanupret from %[[CLEANUPPAD0]] unwind label
 
 // CHECK:   %[[CLEANUPPAD1:.*]] = cleanuppad within %[[CATCHPAD0]] []
 // CHECK:   cleanupret from %[[CLEANUPPAD1]] unwind to caller
 
 // CHECK:   unreachable
+
+// Here we only check if the command enables wasm exception handling in the
+// backend so that exception handling instructions can be generated in .s file.
+
+// ASSEMBLY: try
+// ASSEMBLY: catch
+// ASSEMBLY: rethrow
+// ASSEMBLY: end_try

clang/test/Driver/wasm-toolchain.c

 // PTHREAD_NO_BULK_MEM: invalid argument '-pthread' not allowed with '-mno-bulk-memory'
 
 // '-pthread' not allowed with '-mno-mutable-globals'
 // RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
 // RUN:     --sysroot=/foo %s -pthread -mno-mutable-globals 2>&1 \
 // RUN:   | FileCheck -check-prefix=PTHREAD_NO_MUT_GLOBALS %s
 // PTHREAD_NO_MUT_GLOBALS: invalid argument '-pthread' not allowed with '-mno-mutable-globals'
 
+// '-fwasm-exceptions' sets +exception-handling
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
+// RUN:    --sysroot=/foo %s -fwasm-exceptions 2>&1 \
+// RUN:  | FileCheck -check-prefix=WASM_EXCEPTIONS %s
+// WASM_EXCEPTIONS: clang{{.*}}" "-cc1" {{.*}} "-target-feature" "+exception-handling"
+
+// '-fwasm-exceptions' not allowed with '-mno-exception-handling'
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
+// RUN:     --sysroot=/foo %s -fwasm-exceptions -mno-exception-handling 2>&1 \
+// RUN:   | FileCheck -check-prefix=WASM_EXCEPTIONS_NO_EH %s
+// WASM_EXCEPTIONS_NO_EH: invalid argument '-fwasm-exceptions' not allowed with '-mno-exception-handling'
+
 // RUN: %clang %s -### -fsanitize=address -target wasm32-unknown-emscripten 2>&1 | FileCheck -check-prefix=CHECK-ASAN-EMSCRIPTEN %s
 // CHECK-ASAN-EMSCRIPTEN: "-fsanitize=address"
 // CHECK-ASAN-EMSCRIPTEN: "-fsanitize-address-globals-dead-stripping"