<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in eh-lsda.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>9261ee32 - [WebAssembly] Make EH work with dynamic linking</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#9261ee32</link>
        <description>[WebAssembly] Make EH work with dynamic linkingThis makes Wasm EH work with dynamic linking. So far we were only ableto handle destructors, which do not use any tags or LSDA info.1. This uses `TargetExternalSymbol` for `GCC_except_tableN` symbols,   which points to the address of per-function LSDA info. It is more   convenient to use than `MCSymbol` because it can take additional   target flags.2. When lowering `wasm_lsda` intrinsic, if PIC is enabled, make the   symbol relative to `__memory_base` and generate the `add` node. If   PIC is disabled, continue to use the absolute address.3. Make tag symbols (`__cpp_exception` and `__c_longjmp`) undefined in   the backend, because it is hard to make it work with dynamic   linking&apos;s loading order. Instead, we make all tag symbols undefined   in the LLVM backend and import it from JS.4. Add support for undefined tags to the linker.Companion patches:- https://github.com/WebAssembly/binaryen/pull/4223- https://github.com/emscripten-core/emscripten/pull/15266Reviewed By: sbc100Differential Revision: https://reviews.llvm.org/D111388

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Wed, 29 Sep 2021 21:17:14 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>77b921b8 - [WebAssembly] Tidy up EH/SjLj options</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#77b921b8</link>
        <description>[WebAssembly] Tidy up EH/SjLj optionsThis CL is small, but the description can be a little long because I&apos;mtrying to sum up the status quo for Emscripten/Wasm EH/SjLj options.First, this CL adds an option for Wasm SjLj (`-wasm-enable-sjlj`), whichhandles SjLj using Wasm EH. The implementation for this will be added asa followup CL, but this adds the option first to do error checking.This also adds an option for Wasm EH (`-wasm-enable-eh`), which has beenalready implemented. Before we used `-exception-model=wasm` as the samemeaning as enabling Wasm EH, but after we add Wasm SjLj, it will bepossible to use Wasm EH instructions for Wasm SjLj while not enablingEH, so going forward, to use Wasm EH, `opt` and `llc` will need thisoption. This only affects `opt` and `llc` command lines and does notaffect Emscripten user interface.Now we have two modes of EH (Emscripten/Wasm) and also two modes of SjLj(also Emscripten/Wasm). The options corresponding to each of are:- Emscripten EH: `-enable-emscripten-cxx-exceptions`- Emscripten SjLj: `-enable-emscripten-sjlj`- Wasm EH: `-wasm-enable-eh -exception-model=wasm`           `-mattr=+exception-handling`- Wasm SjLj: `-wasm-enable-sjlj -exception-model=wasm`             `-mattr=+exception-handling`The reason Wasm EH/SjLj&apos;s options are a little complicated are`-exception-model` and `-mattr` are common LLVM options ane not underour control. (`-mattr` can be omitted if it is embedded within thebitcode file.)And we have the following rules of the option composition:- Emscripten EH and Wasm EH cannot be turned on at the same itme- Emscripten SjLj and Wasm SjLj cannot be turned on at the same time- Wasm SjLj should be used with Wasm EHWhich means we now allow these combinations:- Emscripten EH + Emscripten SjLj: the current default in `emcc`- Wasm EH + Emscripten SjLj:  This is allowed, but only as an interim step in which we are testing  Wasm EH but not yet have a working implementation of Wasm SjLj. This  will error out (D107687) in compile time if `setjmp` is called in a  function in which Wasm exception is used.- Wasm EH + Wasm SjLj:  This will be the default mode later when using Wasm EH. Currently Wasm  SjLj implementation doesn&apos;t exist, so it doesn&apos;t work.- Emscripten EH + Wasm SjLj will not work.This CL moves these error checking routines to`WebAssemblyPassConfig::addIRPasses`. Not sure if this is an ideal placeto do this, but I couldn&apos;t find elsewhere. Currently some checking isdone within LowerEmscriptenEHSjLj, but these checks only run ifLowerEmscriptenEHSjLj runs so it may not run when Wasm EH is used. Thismoves that to `addIRPasses` and adds some more checks.Currently LowerEmscriptenEHSjLj pass is responsible for Emscripten EHand Emscripten SjLj. Wasm EH transformations are done in multipleplaces, including WasmEHPrepare, LateEHPrepare, and CFGStackify. But inthe followup CL, LowerEmscriptenEHSjLj pass will be also responsible fora part of Wasm SjLj transformation, because WasmSjLj will also be usingseveral Emscripten library functions, and we will be sharing more thanhalf of the transformation to do that between Emscripten SjLj and WasmSjLj.Currently we have `-enable-emscripten-cxx-exceptions` and`-enable-emscripten-sjlj` but these only work for `llc`, because for`llc` we feed these options to the pass but when we run the pass using`opt` the pass will be created with no options and the default optionswill be used, which turns both Emscripten EH and Emscripten SjLj on.Now we have one more SjLj option to care for, LowerEmscriptenEHSjLj passneeds a finer way to control these options. This CL removes thosedefault parameters and make LowerEmscriptenEHSjLj pass read directlyfrom command line options specified. So if we only run`opt -wasm-lower-em-ehsjlj`, currently both Emscripten EH and EmscriptenSjLj will run, but with this CL, none will run unless we additionallypass `-enable-emscripten-cxx-exceptions` or `-enable-emscripten-sjlj`,or both. This does not affect users; this only affects our `opt` testsbecause `emcc` will not call either `opt` or `llc`. As a result of this,our existing Emscripten EH/SjLj tests gained one or both of thoseoptions in their `RUN` lines.Reviewed By: dschuffDifferential Revision: https://reviews.llvm.org/D107685

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Sat, 07 Aug 2021 02:35:18 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>122b0220 - [WebAssembly] Remove datalayout strings from llc tests</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#122b0220</link>
        <description>[WebAssembly] Remove datalayout strings from llc testsThe data layout strings do not have any effect on llc tests and will becomemisleadingly out of date as we continue to update the canonical data layout, soremove them from the tests.Differential Revision: https://reviews.llvm.org/D105842

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Wed, 14 Jul 2021 18:17:08 +0000</pubDate>
        <dc:creator>Thomas Lively &lt;tlively@google.com&gt;</dc:creator>
    </item>
<item>
        <title>561abd83 - [WebAssembly] Disable uses of __clang_call_terminate</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#561abd83</link>
        <description>[WebAssembly] Disable uses of __clang_call_terminateBackground:Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, usesItanium-based libraries and ABIs with some modifications.`__clang_call_terminate` is a wrapper generated in Clang&apos;s Itanium C++ABI implementation. It contains this code, in C-style pseudocode:```void __clang_call_terminate(void *exn) {  __cxa_begin_catch(exn);  std::terminate();}```So this function is a wrapper to call `__cxa_begin_catch` on theexception pointer before termination.In Itanium ABI, this function is called when another exception is thrownwhile processing an exception. The pointer for this second, violatingexception is passed as the argument of this `__clang_call_terminate`,which calls `__cxa_begin_catch` with that pointer and calls`std::terminate` to terminate the program.The spec (https://libcxxabi.llvm.org/spec.html) for `__cxa_begin_catch`says,```When the personality routine encounters a termination condition, itwill call __cxa_begin_catch() to mark the exception as handled and thencall terminate(), which shall not return to its caller.```In wasm EH&apos;s Clang implementation, this function is called fromcleanuppads that terminates the program, which we also call terminatepads. Cleanuppads normally don&apos;t access the thrown exception and thewasm backend converts them to `catch_all` blocks. But because we needthe exception pointer in this cleanuppad, we generate`wasm.get.exception` intrinsic (which will eventually be lowered to`catch` instruction) as we do in the catchpads. But because terminatepads are cleanup pads and should run even when a foreign exception isthrown, so what we have been doing is:1. In `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()`, we make sureterminate pads are in this simple shape:```%exn = catchcall @__clang_call_terminate(%exn)unreachable```2. In `WebAssemblyHandleEHTerminatePads` pass at the end of thepipeline, we attach a `catch_all` to terminate pads, so they will be inthis form:```%exn = catchcall @__clang_call_terminate(%exn)unreachablecatch_allcall @std::terminate()unreachable```In `catch_all` part, we don&apos;t have the exception pointer, so we call`std::terminate()` directly. The reason we ran HandleEHTerminatePads atthe end of the pipeline, separate from LateEHPrepare, was it wasconvenient to assume there was only a single `catch` part per `try`during CFGSort and CFGStackify.---Problem:While it thinks terminate pads could have been possibly split or callsto `__clang_call_terminate` could have been duplicated,`WebAssemblyLateEHPrepare::ensureSingleBBTermPads()` assumes terminatepads contain no more than calls to `__clang_call_terminate` and`unreachable` instruction. I assumed that because in LLVM very limitedforms of transformations are done to catchpads and cleanuppads tomaintain the scoping structure. But it turned out to be incorrect;passes can merge cleanuppads into one, including terminate pads, as longas the new code has a correct scoping structure. One pass that does thisI observed was `SimplifyCFG`, but there can be more. After thistransformation, a single cleanuppad can contain any number of otherinstructions with the call to `__clang_call_terminate` and can span manyBBs. It wouldn&apos;t be practical to duplicate all these BBs within thecleanuppad to generate the equivalent `catch_all` blocks, only withcalls to `__clang_call_terminate` replaced by calls to `std::terminate`.Unless we do more complicated transformation to split those calls to`__clang_call_terminate` into a separate cleanuppad, it is tricky tosolve.---Solution (?):This CL just disables the generation and use of `__clang_call_terminate`and calls `std::terminate()` directly in its place.The possible downside of this approach can be, because the Itanium ABIintended to &quot;mark&quot; the violating exception handled, we don&apos;t do thatanymore. What `__cxa_begin_catch` actually does is increment theexception&apos;s handler count and decrement the uncaught exception count,which in my opinion do not matter much given that we are about toterminate the program anyway. Also it does not affect info like stacktraces that can be possibly shown to developers.And while we use a variant of Itanium EH ABI, we can make somedeviations if we choose to; we are already different in that in thecurrent version of the EH spec we don&apos;t support two-phase unwinding. Wecan possibly consider a more complicated transformation later toreenable this, but I don&apos;t think that has high priority.Changes in this CL contains:- In Clang, we don&apos;t generate a call to `wasm.get.exception()` intrinsic  and `__clang_call_terminate` function in terminate pads anymore; we  simply generate calls to `std::terminate()`, which is the default  implementation of `CGCXXABI::emitTerminateForUnexpectedException`.- Remove `WebAssembly::ensureSingleBBTermPads() function and  `WebAssemblyHandleEHTerminatePads` pass, because terminate pads are  already `catch_all` now (because they don&apos;t need the exception  pointer) and we don&apos;t need these transformations anymore.- Change tests to use `std::terminate` directly. Also removes tests that  tested `LateEHPrepare::ensureSingleBBTermPads` and  `HandleEHTerminatePads` pass.- Drive-by fix: Add some function attributes to EH intrinsic  declarationsFixes https://github.com/emscripten-core/emscripten/issues/13582.Reviewed By: dschuff, tlivelyDifferential Revision: https://reviews.llvm.org/D97834

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Tue, 02 Mar 2021 23:05:30 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9e4eadeb - [WebAssembly] Update basic EH instructions for the new spec</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#9e4eadeb</link>
        <description>[WebAssembly] Update basic EH instructions for the new specThis implements basic instructions for the new spec.- Adds new versions of instructions: `catch`, `catch_all`, and `rethrow`- Adds support for instruction selection for the new instructions - `catch` needs a custom routine for the same reason `throw` needs one,   to encode `__cpp_exception` tag symbol.- Updates `WebAssembly::isCatch` utility function to include `catch_all`  and Change code that compares an instruction&apos;s opcode with `catch` to  use that function.- LateEHPrepare  - Previously in LateEHPrepare we added `catch` instruction to both    `catchpad`s (for user catches) and `cleanuppad`s (for destructors).    In the new version `catch` is generated from `llvm.catch` intrinsic    in instruction selection phase, so we only need to add `catch_all`    to the beginning of cleanup pads.  - `catch` is generated from instruction selection, but we need to    hoist the `catch` instruction to the beginning of every EH pad,    because `catch` can be in the middle of the EH pad or even in a    split BB from it after various code transformations.  - Removes `addExceptionExtraction` function, which was used to    generate `br_on_exn` before.- CFGStackfiy: Deletes `fixUnwindMismatches` function. Running this  function on the new instruction causes crashes, and the new version  will be added in a later CL, whose contents will be completely  different. So deleting the whole function will make the diff easier to  read.- Reenables all disabled tests in exception.ll and eh-lsda.ll and a  single basic test in cfg-stackify-eh.ll.- Updates existing tests to use the new assembly format. And deletes  `br_on_exn` instructions from the tests and FileCheck lines.Reviewed By: dschuff, tlivelyDifferential Revision: https://reviews.llvm.org/D94040

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Sat, 26 Dec 2020 10:27:44 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9724c3cf - [WebAssembly] Update WasmEHPrepare for the new spec</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#9724c3cf</link>
        <description>[WebAssembly] Update WasmEHPrepare for the new specClang generates `wasm.get.exception` and `wasm.get.ehselector`intrinsics, which respectively return a caught exception value (apointer to some C++ exception struct) and a selector (an integer valuethat tells which C++ `catch` clause the current exception matches, ordoes not match any).WasmEHPrepare is a pass that does some IR-level preparation beforeinstruction selection. Previously one of things we did in this pass wasto convert `wasm.get.exception` intrinsic calls to`wasm.extract.exception` intrinsics. Their semantics were the sameexcept `wasm.extract.exception` did not have a token argument. Wemaintained these two separate intrinsics with the same semantics becauseinstruction selection couldn&apos;t handle token arguments. This`wasm.extract.exception` intrinsic was later converted to`extract_exception` instruction in instruction selection, which was apseudo instruction to implement `br_on_exn`. Because `br_on_exn` pushedan extracted value onto the value stack after the `end` instruction of a`block`, but LLVM does not have a way of modeling that kind of behavior,so this pseudo instruction was used to pull an extracted value out ofthin air, like this:```block $l0  ...  br_on_exn $cpp_exception $l0  ...endextract_exception ;; pushes values onto the stack```In the new spec, we don&apos;t need this pseudo instruction anymore because`catch` itself returns a value and we don&apos;t have `br_on_exn` anymore. Inthe spec `catch` returns multiple values (like `br_on_exn`), but here weassume it only returns a single i32, which is sufficient to support C++.So this renames `wasm.get.exception` intrinsic to `wasm.catch`. Becausethis CL does not yet contain instruction selection for `wasm.catch`intrinsic, all `RUN` lines in exception.ll, eh-lsda.ll, andcfg-stackify-eh.ll, and a single `RUN` line in wasm-eh.cpp (which is anend-to-end test from C++ source to assembly) fail. So this CLtemporarily disables those `RUN` lines, and for those test files withoutany valid remaining `RUN` lines, adds a dummy `RUN` line to make thempass. These tests will be reenabled in later CLs.Reviewed By: dschuff, tlivelyDifferential Revision: https://reviews.llvm.org/D94039

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Sat, 26 Dec 2020 02:38:59 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>24faf859 - Reland &quot;[WebAssembly] LSDA info generation&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#24faf859</link>
        <description>Reland &quot;[WebAssembly] LSDA info generation&quot;Summary:This adds support for LSDA (exception table) generation for wasm EH.Wasm EH mostly follows the structure of Itanium-style exception tables,with one exception: a call site table entry in wasm EH corresponds tonot a call site but a landing pad.In wasm EH, the VM is responsible for stack unwinding. After anexception occurs and the stack is unwound, the control flow istransferred to wasm &apos;catch&apos; instruction by the VM, after which thepersonality function is called from the compiler-generated code. (Referto WasmEHPrepare pass for more information on this part.)This patch:- Changes wasm.landingpad.index intrinsic to take a token argument, tomake this 1:1 match with a catchpad instruction- Stores landingpad index info and catch type info MachineFunction inbefore instruction selection- Lowers wasm.lsda intrinsic to an MCSymbol pointing to the start of anexception table- Adds WasmException class with overridden methods for table generation- Adds support for LSDA section in Wasm object writerReviewers: dschuff, sbc100, rnkSubscribers: mgorny, jgravelle-google, sunfish, llvm-commitsDifferential Revision: https://reviews.llvm.org/D52748llvm-svn: 345345

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Thu, 25 Oct 2018 23:55:10 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>0981eaab - [WebAssembly] LSDA info generation</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll#0981eaab</link>
        <description>[WebAssembly] LSDA info generationSummary:This adds support for LSDA (exception table) generation for wasm EH.Wasm EH mostly follows the structure of Itanium-style exception tables,with one exception: a call site table entry in wasm EH corresponds tonot a call site but a landing pad.In wasm EH, the VM is responsible for stack unwinding. After anexception occurs and the stack is unwound, the control flow istransferred to wasm &apos;catch&apos; instruction by the VM, after which thepersonality function is called from the compiler-generated code. (Referto WasmEHPrepare pass for more information on this part.)This patch:- Changes wasm.landingpad.index intrinsic to take a token argument, tomake this 1:1 match with a catchpad instruction- Stores landingpad index info and catch type info MachineFunction inbefore instruction selection- Lowers wasm.lsda intrinsic to an MCSymbol pointing to the start of anexception table- Adds WasmException class with overridden methods for table generation- Adds support for LSDA section in Wasm object writerReviewers: dschuff, sbc100, rnkSubscribers: mgorny, jgravelle-google, sunfish, llvm-commitsDifferential Revision: https://reviews.llvm.org/D52748llvm-svn: 344575

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/WebAssembly/eh-lsda.ll</description>
        <pubDate>Tue, 16 Oct 2018 00:09:12 +0000</pubDate>
        <dc:creator>Heejin Ahn &lt;aheejin@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
