summaryrefslogtreecommitdiff
path: root/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp
AgeCommit message (Collapse)Author
2025-09-25[WebAssembly] Remove FAKE_USEs before ExplicitLocals (#160768)Heejin Ahn
`FAKE_USE`s are essentially no-ops, so they have to be removed before running ExplicitLocals so that `drop`s will be correctly inserted to drop those values used by the `FAKE_USE`s. --- This is reapplication of #160228, which broke Wasm waterfall. This PR additionally prevents `FAKE_USE`s uses from being stackified. Previously, a 'def' whose first use was a `FAKE_USE` was able to be stackified as `TEE`: - Before ``` Reg = INST ... // Def FAKE_USE ..., Reg, ... // Insert INST ..., Reg, ... INST ..., Reg, ... ``` - After RegStackify ``` DefReg = INST ... // Def TeeReg, Reg = TEE ... DefReg FAKE_USE ..., TeeReg, ... // Insert INST ..., Reg, ... INST ..., Reg, ... ``` And this assumes `DefReg` and `TeeReg` are stackified. But this PR removes `FAKE_USE`s in the beginning of ExplicitLocals. And later in ExplicitLocals we have a routine to unstackify registers that have no uses left: https://github.com/llvm/llvm-project/blob/7b28fcd2b182ba2c9d2d71c386be92fc0ee3cc9d/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp#L257-L269 (This was added in #149626. Then it didn't seem it would trigger the same assertions for `TEE`s because it was fixing the bug where a terminator was removed in CFGSort (#149097). Details here: https://github.com/llvm/llvm-project/pull/149432#issuecomment-3091444141) - After `FAKE_USE` removal and unstackification ``` DefReg = INST ... TeeReg, Reg = TEE ... DefReg INST ..., Reg, ... INST ..., Reg, ... ``` And now `TeeReg` is unstackified. This triggered the assertion here, that `TeeReg` should be stackified: https://github.com/llvm/llvm-project/blob/7b28fcd2b182ba2c9d2d71c386be92fc0ee3cc9d/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp#L316 This prevents `FAKE_USE`s' uses from being stackified altogether, including `TEE` transformation. Even when it is not a `TEE` transformation and just a single use stackification, it does not trigger the assertion but there's no point stackifying it given that it will be deleted. --- Fixes https://github.com/emscripten-core/emscripten/issues/25301.
2025-09-24Revert "[WebAssembly] Remove FAKE_USEs before ExplicitLocals" (#160553)Derek Schuff
Reverts llvm/llvm-project#160228 See https://github.com/llvm/llvm-project/pull/160228#issuecomment-3329752471
2025-09-23[WebAssembly] Remove FAKE_USEs before ExplicitLocals (#160228)Heejin Ahn
`FAKE_USE`s are essentially no-ops, so they have to be removed before running ExplicitLocals so that `drop`s will be correctly inserted to drop those values used by the `FAKE_USE`s. Fixes https://github.com/emscripten-core/emscripten/issues/25301.
2025-07-22[WebAssembly] Unstackify registers with no uses in ExplicitLocals (#149626)Heejin Ahn
There are cases we end up removing some intructions that use stackified registers after RegStackify. For example, ```wasm bb.0: %0 = ... ;; %0 is stackified br_if %bb.1, %0 bb.1: ``` In this code, br_if will be removed in CFGSort, so we should unstackify %0 so that it can be correctly dropped in ExplicitLocals. Rather than handling this in case-by-case basis, this PR just unstackifies all stackifies register with no uses in the beginning of ExplicitLocals, so that they can be correctly dropped. Fixes #149097.
2025-02-19[CodeGen] Remove static member function Register::virtReg2Index. NFC (#127962)Craig Topper
Use the nonstatic member instead. I'm pretty sure the code in SPRIV is a layering violation. MC layer files are using a CodeGen header.
2025-01-30[CodeGen] Use non-static Register::virtRegIndex() instead of static ↵Craig Topper
Register::virtReg2Index. NFC (#125031) These are the the ones where we already had a Register object being used. Some places are still using unsigned which I did not convert.
2024-07-12[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)paperchalice
- Add `MachineBlockFrequencyAnalysis`. - Add `MachineBlockFrequencyPrinterPass`. - Use `MachineBlockFrequencyInfoWrapperPass` in legacy pass manager. - `LazyMachineBlockFrequencyInfo::print` is empty, drop it due to new pass manager migration.
2024-05-28[WebAssembly] Add exnref type (#93586)Heejin Ahn
This adds (back) the exnref type restored in the new EH proposal adopted in Oct 2023 CG meeting: https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md:x
2023-08-18[WebAssembly] Create separation between MC and CodeGen layersReid Kleckner
Move WebAssemblyUtilities from Utils to the CodeGen library. It primarily deals in MIR layer types, so it really lives in the CodeGen library. Move a variety of other things around to try create better separation. See issue #64166 for more info on layering. Move llvm/include/CodeGen/WasmAddressSpaces.h back to llvm/lib/Target/WebAssembly/Utils. Differential Revision: https://reviews.llvm.org/D156472
2023-03-17[WebAssembly] Add comments on local.tee transformationHeejin Ahn
We have a good comment on `TEE` transformation in `RegStackify`: https://github.com/llvm/llvm-project/blob/547e3456660000a16fc5c2a2f819f1a2b5d35b5d/llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp#L613-L632 And I think it can be helpful to have some more comments on how the `TEE`s created in `RegStackify` are converted into `LOCAL_TEE`s. Variable `OldReg` is changed to `DefReg` to be consistent with `RegStackify`'s comment. Reviewed By: tlively Differential Revision: https://reviews.llvm.org/D146084
2023-02-07[CodeGen] Make more use of MachineOperand::getOperandNo. NFC.Jay Foad
Differential Revision: https://reviews.llvm.org/D143252
2022-01-19[NFC] Use Register instead of unsignedJim Lin
2021-11-04[WebAssembly] Fix debug locations for ExplicitLocals passWouter van Oortmerssen
This is a reworked version of the reverted patch: https://reviews.llvm.org/D112487 Note that a) it doesn't need the test changes anymore, and b) I checked at least locally it passes other.test_pthread_lsan_leak Differential Revision: https://reviews.llvm.org/D113208
2021-10-29Revert "[WebAssembly] Fix debug locations for ExplicitLocals pass"Sam Clegg
This reverts commit a66451ebbe450a5e9dc6baf0c4e9f5738df589a2. This caused a failure when integrated with emscripten: https://ci.chromium.org/ui/p/emscripten-releases/builders/try/linux/b8832019855439718609/overview
2021-10-28[WebAssembly] Fix debug locations for ExplicitLocals passWouter van Oortmerssen
Differential Revision: https://reviews.llvm.org/D112487
2021-09-20[llvm] Use make_early_inc_range (NFC)Kazu Hirata
2021-06-01[WebAssembly][CodeGen] IR support for WebAssembly local variablesAndy Wingo
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a pointer to memory. For the WebAssembly target, these objects are lowered to WebAssembly local variables, which are managed by the WebAssembly run-time and are not addressable by linear memory. For the WebAssembly target IR indicates that an AllocaInst should be put on TargetStackID::WasmLocal by putting it in the non-integral address space WASM_ADDRESS_SPACE_WASM_VAR, with value 1. SROA will mostly lift these allocations to SSA locals, but any alloca that reaches instruction selection (usually in non-optimized builds) will be assigned the new TargetStackID there. Loads and stores to those values are transformed to new WebAssemblyISD::LOCAL_GET / WebAssemblyISD::LOCAL_SET nodes, which then lower to the type-specific LOCAL_GET_I32 etc instructions via tablegen patterns. Differential Revision: https://reviews.llvm.org/D101140
2021-05-31Revert "[WebAssembly][CodeGen] IR support for WebAssembly local variables"Andy Wingo
This reverts commit bf35f4af51cddd743435bb6b94a45592c967891a. There was an error in a shared-library build.
2021-05-31[WebAssembly][CodeGen] IR support for WebAssembly local variablesAndy Wingo
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a pointer to memory. For the WebAssembly target, these objects are lowered to WebAssembly local variables, which are managed by the WebAssembly run-time and are not addressable by linear memory. For the WebAssembly target IR indicates that an AllocaInst should be put on TargetStackID::WasmLocal by putting it in the non-integral address space WASM_ADDRESS_SPACE_WASM_VAR, with value 1. SROA will mostly lift these allocations to SSA locals, but any alloca that reaches instruction selection (usually in non-optimized builds) will be assigned the new TargetStackID there. Loads and stores to those values are transformed to new WebAssemblyISD::LOCAL_GET / WebAssemblyISD::LOCAL_SET nodes, which then lower to the type-specific LOCAL_GET_I32 etc instructions via tablegen patterns. Differential Revision: https://reviews.llvm.org/D101140
2021-05-28Revert "[WebAssembly][CodeGen] IR support for WebAssembly local variables"Andy Wingo
This reverts commit 00ecf18979e3326b3afee8af3dc701c53ffdc93f, as it broke the AMDGPU build. Will reland later with a fix.
2021-05-28[WebAssembly][CodeGen] IR support for WebAssembly local variablesAndy Wingo
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a pointer to memory. For the WebAssembly target, these objects are lowered to WebAssembly local variables, which are managed by the WebAssembly run-time and are not addressable by linear memory. For the WebAssembly target IR indicates that an AllocaInst should be put on TargetStackID::WasmLocal by putting it in the non-integral address space WASM_ADDRESS_SPACE_WASM_VAR, with value 1. SROA will mostly lift these allocations to SSA locals, but any alloca that reaches instruction selection (usually in non-optimized builds) will be assigned the new TargetStackID there. Loads and stores to those values are transformed to new WebAssemblyISD::LOCAL_GET / WebAssemblyISD::LOCAL_SET nodes, which then lower to the type-specific LOCAL_GET_I32 etc instructions via tablegen patterns. Differential Revision: https://reviews.llvm.org/D101140
2021-05-24[WebAssembly] Add NullifyDebugValueLists passHeejin Ahn
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the constructor of `WebAssemblyDebugValueManager` in D102589, but it made the class error-prone to use because it deletes instructions within the constructor and thus invalidates existing iterators within the BB, so the user of the class should take special care not to use invalidated iterators. This actually caused a bug in ExplicitLocals pass. Instead of trying to fix ExplicitLocals pass to make the iterator usage correct, which is possible but error-prone, this adds NullifyDebugValueLists pass that nullifies all `DBG_VALUE_LIST` instructions before we run WebAssembly specific passes in the backend. We can remove this pass after we implement handlers for `DBG_VALUE_LIST`s in `WebAssemblyDebugValueManager` and elsewhere. Fixes https://github.com/emscripten-core/emscripten/issues/14255. Reviewed By: dschuff Differential Revision: https://reviews.llvm.org/D102999
2021-05-17[WebAssembly] Nullify DBG_VALUE_LISTs in DebugValueManagerHeejin Ahn
WebAssemblyDebugValueManager class currently does not handle DBG_VALUE_LIST instructions correctly for two reasons, which are explained in https://bugs.llvm.org/show_bug.cgi?id=50361. This effectively nullifies DBG_VALUE_LISTs in WebAssemblyDebugValueManager so that the info will appear as "optimized out" in debuggers but still be at least correct in the meantime. Reviewed By: dschuff, jmorse Differential Revision: https://reviews.llvm.org/D102589
2021-04-22[WebAssembly] Put utility functions in Utils directory (NFC)Heejin Ahn
This CL 1. Creates Utils/ directory under lib/Target/WebAssembly 2. Moves existing WebAssemblyUtilities.cpp|h into the Utils/ directory 3. Creates Utils/WebAssemblyTypeUtilities.cpp|h and put type declarataions and type conversion functions scattered in various places into this single place. It has been suggested several times that it is not easy to share utility functions between subdirectories (AsmParser, DIsassembler, MCTargetDesc, ...). Sometimes we ended up [[ https://reviews.llvm.org/D92840#2478863 | duplicating ]] the same function because of this. There are already other targets doing this: AArch64, AMDGPU, and ARM have Utils/ subdirectory under their target directory. This extracts the utility functions into a single directory Utils/ and make them sharable among all passes in WebAssembly/ and its subdirectories. Also I believe gathering all type-related conversion functionalities into a single place makes it more usable. (Actually I was working on another CL that uses various type conversion functions scattered in multiple places, which became the motivation for this CL.) Reviewed By: dschuff, aardappel Differential Revision: https://reviews.llvm.org/D100995
2021-01-09[WebAssembly] Remove exnref and br_on_exnHeejin Ahn
This removes `exnref` type and `br_on_exn` instruction. This is effectively NFC because most uses of these were already removed in the previous CLs. Reviewed By: dschuff, tlively Differential Revision: https://reviews.llvm.org/D94041
2021-01-07[WebAssembly] Fixed byval args missing DWARF DW_AT_LOCATIONWouter van Oortmerssen
A struct in C passed by value did not get debug information. Such values are currently lowered to a Wasm local even in -O0 (not to an alloca like on other archs), which becomes a Target Index operand (TI_LOCAL). The DWARF writing code was not emitting locations in for TI's specifically if the location is a single range (not a list). In addition, the ExplicitLocals pass which removes the ARGUMENT pseudo instructions did not update the associated DBG_VALUEs, and couldn't even find these values since the code assumed such instructions are adjacent, which is not the case here. Also fixed asm printing of TIs needed by a test. Differential Revision: https://reviews.llvm.org/D94140
2020-12-01[WebAssembly] Support select and block for reference typesHeejin Ahn
This adds missing `select` instruction support and block return type support for reference types. Also refactors WebAssemblyInstrRef.td and rearranges tests in reference-types.s. Tests don't include `exnref` types, because we currently don't support `exnref` for `ref.null` and the type will be removed soon anyway. Reviewed By: tlively, sbc100, wingo Differential Revision: https://reviews.llvm.org/D92359
2020-10-23[WebAssembly] Implementation of (most) table instructionsPaulo Matos
Implementation of instructions table.get, table.set, table.grow, table.size, table.fill, table.copy. Missing instructions are table.init and elem.drop as they deal with element sections which are not yet implemented. Added more tests to tables.s Differential Revision: https://reviews.llvm.org/D89797
2020-06-24WebAssembly: Don't store MachineFunction in MachineFunctionInfoMatt Arsenault
Soon it will be disallowed to depend on MachineFunction state in the constructor. This was only being used to get the MachineRegisterInfo for an assert, which I'm not sure is necessarily worth it. I would think any missing defs would be caught by the verifier later instead.
2020-05-14[WebAssembly] Added Debug Fixup passWouter van Oortmerssen
This pass changes debug_value instructions referring to stackified registers into TI_OPERAND_STACK with correct stack depth.
2020-03-26[WEbAssembly] Clear frame base vreg in explicit-locals when stack pointer is ↵Derek Schuff
dead Having an alloca in a function causes the stack pointer to be generated in the prolog, but if it's unused other than for debug info, explicit-locals will drop it and not allocate a local. In this case we need to reset the FrameBaseVreg. Differential Revision: https://reviews.llvm.org/D76784
2020-03-09[WebAssembly] Fixed FrameBaseLocal not being set.Wouter van Oortmerssen
Summary: Fixes: https://bugs.llvm.org/show_bug.cgi?id=44920 WebAssemblyRegColoring may merge the vreg that currently represents the FrameBase with one representing an argument. WebAssemblyExplicitLocals picks up the corresponding local when a vreg is first added to the Reg2Local mapping, except when it is an argument instruction which are handled separately. Note that this does not change that vregs representing the FrameBase may get merged, it is not clear to me that this may have other effects we may want to avoid? Reviewers: dschuff Reviewed By: dschuff Subscribers: azakai, sbc100, hiraditya, aheejin, sunfish, llvm-commits, jgravelle-google Tags: #llvm Differential Revision: https://reviews.llvm.org/D75718
2020-02-18[WebAssembly] Fix RegStackify and ExplicitLocals to handle multivalueThomas Lively
Summary: There is still room for improvement in the handling of multivalue nodes in both passes, but the current algorithm is at least correct and optimizes some simpler cases. In order to make future optimizations of these passes easier and build confidence that the current algorithms are correct, this CL also adds a script that automatically and exhaustively generates interesting multivalue test cases. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72902
2020-01-28[WebAssembly] Preserve debug frame base information through register coloringDerek Schuff
2 fixes: Register coloring can re-assign virtual registers. When the frame base register is colored, update the DwarfFrameBase accordingly When the frame base register is stackified, do not attempt to encode DW_AT_frame_base as a local In the future we will presumably want to handle this case better but for now we can emit worse debug info rather than crashing. Differential Revision: https://reviews.llvm.org/D73581
2020-01-17[WebAssembly] Track frame registers through VReg and local allocationDerek Schuff
This change has 2 components: Target-independent: add a method getDwarfFrameBase to TargetFrameLowering. It describes how the Dwarf frame base will be encoded. That can be a register (the default), the CFA (which replaces NVPTX-specific logic in DwarfCompileUnit), or a DW_OP_WASM_location descriptr. WebAssembly: Allow WebAssemblyFunctionInfo::getFrameRegister to return the correct virtual register instead of FP32/SP32 after WebAssemblyReplacePhysRegs has run. Make WebAssemblyExplicitLocals store the local it allocates for the frame register. Use this local information to implement getDwarfFrameBase The result is that the DW_AT_frame_base attribute is correctly encoded for each subprogram, and each param and local variable has a correct DW_AT_location that uses DW_OP_fbreg to refer to the frame base. This is a reland of rG3a05c3969c18 with fixes for the expensive-checks and Windows builds Differential Revision: https://reviews.llvm.org/D71681
2020-01-16Revert "[WebAssembly] Track frame registers through VReg and local allocation"Derek Schuff
This reverts commit 3a05c3969c18b5520e360b78fc63cda39a6be98f. It breaks under expensive-checks and on Windows
2020-01-16[WebAssembly] Track frame registers through VReg and local allocationDerek Schuff
This change has 2 components: Target-independent: add a method getDwarfFrameBase to TargetFrameLowering. It describes how the Dwarf frame base will be encoded. That can be a register (the default), the CFA (which replaces NVPTX-specific logic in DwarfCompileUnit), or a DW_OP_WASM_location descriptr. WebAssembly: Allow WebAssemblyFunctionInfo::getFrameRegister to return the correct virtual register instead of FP32/SP32 after WebAssemblyReplacePhysRegs has run. Make WebAssemblyExplicitLocals store the local it allocates for the frame register. Use this local information to implement getDwarfFrameBase The result is that the DW_AT_frame_base attribute is correctly encoded for each subprogram, and each param and local variable has a correct DW_AT_location that uses DW_OP_fbreg to refer to the frame base. Differential Revision: https://reviews.llvm.org/D71681
2019-12-20[WebAssembly] Use TargetIndex operands in DbgValue to track WebAssembly ↵Yury Delendik
operands locations Extends DWARF expression language to express locals/globals locations. (via target-index operands atm) (possible variants are: non-virtual registers or address spaces) The WebAssemblyExplicitLocals can replace virtual registers to targertindex operand type at the time when WebAssembly backend introduces {get,set,tee}_local instead of corresponding virtual registers. Reviewed By: aprantl, dschuff Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D52634
2019-08-12[webassembly] Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Reviewers: aheejin Subscribers: jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision for whole review: https://reviews.llvm.org/D65962 llvm-svn: 368627
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-07-15[WebAssembly] Rename except_ref type to exnrefHeejin Ahn
Summary: We agreed to rename `except_ref` to `exnref` for consistency with other reference types in https://github.com/WebAssembly/exception-handling/issues/79. This also renames WebAssemblyInstrExceptRef.td to WebAssemblyInstrRef.td in order to use the file for other reference types in future. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64703 llvm-svn: 366145
2019-07-12[WebAssembly] refactored utilities to not depend on MachineInstrWouter van Oortmerssen
Summary: Most of these functions can work for MachineInstr and MCInst equally now. Reviewers: dschuff Subscribers: MatzeB, sbc100, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64643 llvm-svn: 365965
2019-03-19[WebAssembly] Rename methods according to instruction name changes (NFC)Heejin Ahn
Reviewers: tlively, sbc100 Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59469 llvm-svn: 356438
2019-03-05[WebAssembly] Simplify iterator navigations (NFC)Heejin Ahn
Summary: - Replaces some uses of `MachineFunction::iterator(MBB)` with `MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with `MI->getIterator()`, which are simpler. - Replaces some uses of `std::prev` of `std::next` that takes a MachineFunction or MachineBasicBlock iterator with `getPrevNode` and `getNextNode`, which are also simpler. Reviewers: sbc100 Subscribers: dschuff, sunfish, jgravelle-google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58913 llvm-svn: 355444
2019-02-04[CodeGen][ARC][SystemZ][WebAssembly] Use MachineInstr::isInlineAsm in more ↵Craig Topper
places instead of just comparing opcode. NFCI I'm looking at adding a second INLINEASM opcode for better modeling asm-goto as a terminator. Using the existing predicate will reduce teh number of places that will need to use the new opcode. llvm-svn: 353095
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-08[WebAssembly] Massive instruction renamingThomas Lively
Summary: An automated renaming of all the instructions listed at https://github.com/WebAssembly/spec/issues/884#issuecomment-426433329 as well as some similarly-named identifiers. Reviewers: aheejin, dschuff, aardappel Subscribers: sbc100, jgravelle-google, eraman, sunfish, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D56338 llvm-svn: 350609
2018-12-29[WebAssembly] Fix comments in ExplicitLocals (NFC)Heejin Ahn
llvm-svn: 350144
2018-10-09[WebAssembly] Handle V128 register class in explicit locals passThomas Lively
Summary: Also add tests to catch crashes in passes that are not normally run in tests. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D52959 llvm-svn: 344094
2018-09-12[WebAssembly] Make tied inline asm operands work againHeejin Ahn
Summary: rL341389 broke code with tied register operands in inline assembly. For example, `asm("" : "=r"(var) : "0"(var));` The code above specifies the input operand to be in the same register with the output operand, tying the two register. This patch makes this kind of code work again. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, eraman, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51991 llvm-svn: 342084