aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp
AgeCommit message (Collapse)AuthorFilesLines
3 days[WebAssembly] Remove FAKE_USEs before ExplicitLocals (#160768)Heejin Ahn1-0/+4
`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.
4 days[TII] Split isTrivialReMaterializable into two versions [nfc] (#160377)Philip Reames1-4/+1
This change builds on https://github.com/llvm/llvm-project/pull/160319 which tries to clarify which *callers* (not backends) assume that the result is actually trivial. This change itself should be NFC. Essentially, I'm just renaming the existing isTrivialRematerializable to the non-trivial version and then adding a new trivial version (with the same name as the prior function) and simplifying a few callers which want that semantic. This change does *not* enable non-trivial remat any more broadly than was already done for our targets which were lying through the old APIs; that will come separately. The goal here is simply to make the code easier to follow in terms of what assumptions are being made where. --------- Co-authored-by: Luke Lau <luke_lau@icloud.com>
6 daysUpdate callers of isTriviallyReMaterializable to check trivialness (#160319)Philip Reames1-1/+4
This is a preparatory change for an upcoming reorganization of our rematerialization APIs. Despite the interface being documented as "trivial" (meaning no virtual register uses on the instruction being considered for remat), our actual implementation inconsistently supports non-trivial remat, and certain backends (AMDGPU and RISC-V mostly) lie about instructions being trivial to abuse that. We want to allow non-triial remat more broadly, but first we need to do some cleanup to make it understandable what's going on. These three call sites are ones which appear to actually want the trivial definition, and appear fairly low risk to change. p.s. I'm deliberately *not* updating any APIs in this change, I'm going to do that as a followup once it's clear which category each callsite fits in.
2025-09-02[WebAssembly] Guard use of getSymbolName with isSymbol (#156105)Derek Schuff1-1/+2
WebAssemblyRegStackfy checks for writes to the stack pointer to avoid stackifying across them, but it wasn't prepared for other global_set instructions (such as writes in addrspace 1). Fixes #156055 Thanks to @QuantumSegfault for reporting and identifying the offending code.
2025-06-24[WebAssembly] Enable a limited amount of stackification for debug code (#136510)SingleAccretion1-49/+89
This change is a step towards fixing one long-standing problem with LLVM's debug WASM codegen: excessive use of locals. One local for each temporary value in IR (roughly speaking). This has a lot of problems: 1) It makes it easy to hit engine limitations of 50K locals with certain code patterns and large functions. 2) It makes for larger binaries that are slower to load and slower to compile to native code. 3) It makes certain compilation strategies (spill all WASM locals to stack, for example) for debug code excessively expensive and makes debug WASM code either run very slow, or be less debuggable. 4) It slows down LLVM itself. This change addresses these partially by running a limited version of the stackification pass for unoptimized code, one that gets rid of the most 'obviously' unnecessary locals. Care needs to be taken to not impact LLVM's ability to produce high quality debug variable locations with this pass. To that end: 1) We only allow stackification when it doesn't require moving any instructions. 2) We disable stackification of any locals that are used in DEBUG_VALUEs, or as a frame base. I have verified on a moderately large example that the baseline and the diff produce the same kinds (local/global/stack) of locations, and the only differences are due to the shifting of instruction offsets, with many local.[get|set]s not being present anymore. Even with this quite conservative approach, the results are pretty good: 1) 30% reduction in raw code size, up to 10x reduction in the number of locals for select large methods (~1000 => ~100). 2) ~10% reduction in instructions retired for an "llc -O0" run on a moderately sized input.
2024-11-15[WebAssembly] Remove unused includes (NFC) (#116318)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-07-12[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)paperchalice1-1/+1
- Add `MachineBlockFrequencyAnalysis`. - Add `MachineBlockFrequencyPrinterPass`. - Use `MachineBlockFrequencyInfoWrapperPass` in legacy pass manager. - `LazyMachineBlockFrequencyInfo::print` is empty, drop it due to new pass manager migration.
2024-07-10[CodeGen][NewPM] Port `LiveIntervals` to new pass manager (#98118)paperchalice1-3/+3
- Add `LiveIntervalsAnalysis`. - Add `LiveIntervalsPrinterPass`. - Use `LiveIntervalsWrapperPass` in legacy pass manager. - Use `std::unique_ptr` instead of raw pointer for `LICalc`, so destructor and default move constructor can handle it correctly. This would be the last analysis required by `PHIElimination`.
2024-07-09[CodeGen][NewPM] Port `SlotIndexes` to new pass manager (#97941)paperchalice1-1/+1
- Add `SlotIndexesAnalysis`. - Add `SlotIndexesPrinterPass`. - Use `SlotIndexesWrapperPass` in legacy pass.
2024-06-28[IR] Don't include Module.h in Analysis.h (NFC) (#97023)Nikita Popov1-0/+1
Replace it with a forward declaration instead. Analysis.h is pulled in by all passes, but not all passes need to access the module.
2024-06-11[CodeGen][NewPM] Split `MachineDominatorTree` into a concrete analysis ↵paperchalice1-3/+3
result (#94571) Prepare for new pass manager version of `MachineDominatorTreeAnalysis`. We may need a machine dominator tree version of `DomTreeUpdater` to handle `SplitCriticalEdge` in some CodeGen passes.
2024-05-28[WebAssembly] Add exnref type (#93586)Heejin Ahn1-0/+2
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
2024-04-24[CodeGen] Make the parameter TRI required in some functions. (#85968)Xu Zhang1-5/+6
Fixes #82659 There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI parameters, as shown in issue #82411. Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`, `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact. After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.
2023-11-11[llvm] Stop including llvm/ADT/SmallPtrSet.h (NFC)Kazu Hirata1-1/+0
Identified with clangd.
2023-08-18[WebAssembly] Create separation between MC and CodeGen layersReid Kleckner1-1/+1
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-29[WebAssembly] Redesign DebugValueManagerHeejin Ahn1-32/+33
The current `DebugValueManager`, which is mostly used in `RegStackify`, simply sinks `DBG_VALUE`s along when a def instruction sinks. (`RegStackify` only does sinks; it doesn't do hoists.) But this simple strategy can result in incorrect combinations of variables' values which would have not been possible in the original program. In this case, LLVM's policy is to make the value unavailable, so they will be shown as 'optimized out', rather than showing inaccurate debug info. Especially, when an instruction sinks, its original `DBG_VALUE` should be set to undef. This is well illustrated in the third example in https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling. This CL rewrites `DebugValueManager` with this principle in mind. When sinking an instruction, it sinks its eligible `DBG_VALUE`s with it, but also leaves undef `DBG_VALUE`s in the original place to make those variables' values undefined. Also, unlike the current version, we sink only an eligible subset of `DBG_VALUE`s with a def instruction. See comments in the code for details. In case of cloning, because the original def is still there, we don't set its `DBG_VALUE`s to undef. But we clone only an eligible subset of `DBG_VALUE`s here as well. One consequence of this change is that now we do sinking and cloning of the def instruction itself within the `DebugValueManager`'s `sink` and `clone` methods. This is necessary because the `DebugValueManager` needs to know the original def's location before sinking and cloning in order to scan other interfering `DBG_VALUE`s between the original def and the insertion point. If we want to separate these two, we need to call `DebugValueManager`'s `sink` and `clone` methods //before// sinking/cloning the def instruction, which I don't think is a good design alternative either, because the user of this class needs to pay extra attention when using it. Because this change is fixing the existing inaccuracy of the current debug info, this reduces the variable info coverage in debug info, but not by a large margin. In Emscripten core benchmarks compiled with `-O1`, the coverage goes from 56.6% down to 55.2%, which I doubt will be a noticeable drop. The compilation time doesn't have any meaningful difference either with this change. Reviewed By: dschuff Differential Revision: https://reviews.llvm.org/D146744
2023-01-13[CodeGen][Target] Remove uses of ↵Craig Topper1-4/+3
Register::isPhysicalRegister/isVirtualRegister. NFC Use isPhysical/isVirtual methods.
2022-11-16[WebAssembly] multivalue stackify fixSamuel Parker1-5/+10
Don't attempt to move a multivalue def past one of it's prior uses. Differential Revision: https://reviews.llvm.org/D137824
2022-07-18CodeGen: Remove AliasAnalysis from regallocMatt Arsenault1-13/+10
This was stored in LiveIntervals, but not actually used for anything related to LiveIntervals. It was only used in one check for if a load instruction is rematerializable. I also don't think this was entirely correct, since it was implicitly assuming constant loads are also dereferenceable. Remove this and rely only on the invariant+dereferenceable flags in the memory operand. Set the flag based on the AA query upfront. This should have the same net benefit, but has the possible disadvantage of making this AA query nonlazy. Preserve the behavior of assuming pointsToConstantMemory implying dereferenceable for now, but maybe this should be changed.
2022-01-19[NFC] Use Register instead of unsignedJim Lin1-2/+2
2021-10-20[WebAssembly] Implementation of table.get/set for reftypes in LLVM IRPaulo Matos1-0/+4
This change implements new DAG nodes TABLE_GET/TABLE_SET, and lowering methods for load and stores of reference types from IR arrays. These global LLVM IR arrays represent tables at the Wasm level. Differential Revision: https://reviews.llvm.org/D111154
2021-04-22[WebAssembly] Put utility functions in Utils directory (NFC)Heejin Ahn1-1/+1
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-04-19[WebAssembly] Use v128.const instead of splats for constantsThomas Lively1-8/+3
We previously used splats instead of v128.const to materialize vector constants because V8 did not support v128.const. Now that V8 supports v128.const, we can use v128.const instead. Although this increases code size, it should also increase performance (or at least require fewer engine-side optimizations), so it is an appropriate change to make. Differential Revision: https://reviews.llvm.org/D100716
2021-01-18[llvm] Use the default value of drop_begin (NFC)Kazu Hirata1-2/+2
2021-01-16[llvm] Use *::empty (NFC)Kazu Hirata1-6/+5
2021-01-09[WebAssembly] Remove exnref and br_on_exnHeejin Ahn1-18/+0
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-09[WebAssembly] Update basic EH instructions for the new specHeejin Ahn1-4/+3
This 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'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, tlively Differential Revision: https://reviews.llvm.org/D94040
2020-12-28[WebAssembly][NFC] Finish cleaning up SIMD tablegenThomas Lively1-1/+1
This commit is a follow-on to c2c2e9119e73, using the `Vec` records introduced in that commit in the rest of the SIMD instruction definitions. Also removes unnecessary types in output patterns. Differential Revision: https://reviews.llvm.org/D93771
2020-10-08[NFC][MC] MCRegister API typing.Mircea Trofin1-1/+1
Mostly LiveIntervals, with their effects (users). Differential Revision: https://reviews.llvm.org/D89018
2020-06-25[WebAssembly] Adding 64-bit versions of __stack_pointer and other globalsWouter van Oortmerssen1-1/+2
We have 6 globals, all of which except for __table_base are 64-bit under wasm64. Differential Revision: https://reviews.llvm.org/D82130
2020-06-24WebAssembly: Don't store MachineFunction in MachineFunctionInfoMatt Arsenault1-6/+6
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-02-19[WebAssembly] Fix memory bug introduced in 52861809994cThomas Lively1-2/+2
Summary: The instruction at `DefI` can sometimes be destroyed by `rematerializeCheapDef`, so it should not be used after calling that function. The fix is to use `Insert` instead when examining additional multivalue stackifications. `Insert` is the address of the new defining instruction after all moves and rematerializations have taken place. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74875
2020-02-18[WebAssembly] Fix RegStackify and ExplicitLocals to handle multivalueThomas Lively1-45/+106
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-02-18Reland "[WebAssembly][InstrEmitter] Foundation for multivalue call lowering"Thomas Lively1-5/+4
This reverts commit 649aba93a27170cb03a4b17c98a19b9237a880b8, now that the approach started there has been shown to be workable in the patch series culminating in https://reviews.llvm.org/D74192.
2020-02-04Revert "[WebAssembly][InstrEmitter] Foundation for multivalue call lowering"Thomas Lively1-4/+5
Summary: This reverts commit 3ef169e586f4d14efe690c23c878d5aa92a80eb5. The purpose of this commit was to allow stack machines to perform instruction selection for instructions with variadic defs. However, MachineInstrs fundamentally cannot support variadic defs right now, so this change does not turn out to be useful. Depends on D73927. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73928
2020-01-28[WebAssembly] Preserve debug frame base information through register coloringDerek Schuff1-0/+6
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-21[WebAssembly][InstrEmitter] Foundation for multivalue call loweringThomas Lively1-5/+4
Summary: WebAssembly is unique among upstream targets in that it does not at any point use physical registers to store values. Instead, it uses virtual registers to model positions in its value stack. This means that some target-independent lowering activities that would use physical registers need to use virtual registers instead for WebAssembly and similar downstream targets. This CL generalizes the existing `usesPhysRegsForPEI` lowering hook to `usesPhysRegsForValues` in preparation for using it in more places. One such place is in InstrEmitter for instructions that have variadic defs. On register machines, it only makes sense for these defs to be physical registers, but for WebAssembly they must be virtual registers like any other values. This CL changes InstrEmitter to check the new target lowering hook to determine whether variadic defs should be physical or virtual registers. These changes are necessary to support a generalized CALL instruction for WebAssembly that is capable of returning an arbitrary number of arguments. Fully implementing that instruction will require additional changes that are described in comments here but left for a follow up commit. Reviewers: aheejin, dschuff, qcolombet Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71484
2019-08-12[webassembly] Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-9/+9
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 Sanders1-3/+3
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-07-15[WebAssembly] Rename except_ref type to exnrefHeejin Ahn1-3/+3
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 Oortmerssen1-2/+2
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-02-04[CodeGen][ARC][SystemZ][WebAssembly] Use MachineInstr::isInlineAsm in more ↵Craig Topper1-3/+3
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-02-04[WebAssembly] clang-tidy (NFC)Heejin Ahn1-64/+62
Summary: This patch fixes clang-tidy warnings on wasm-only files. The list of checks used is: `-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming,modernize-*` (LLVM's default .clang-tidy list is the same except it does not have `modernize-*`. But I've seen in multiple CLs in LLVM the modernize style was recommended and code was fixed based on the style, so I added it as well.) The common fixes are: - Variable names start with an uppercase letter - Function names start with a lowercase letter - Use `auto` when you use casts so the type is evident - Use inline initialization for class member variables - Use `= default` for empty constructors / destructors - Use `using` in place of `typedef` Reviewers: sbc100, tlively, aardappel Subscribers: dschuff, sunfish, jgravelle-google, yurydelendik, kripken, MatzeB, mgorny, rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D57500 llvm-svn: 353075
2019-01-30[WebAssembly] Exception handling: Switch to the new proposalHeejin Ahn1-0/+30
Summary: This switches the EH implementation to the new proposal: https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md (The previous proposal was https://github.com/WebAssembly/exception-handling/blob/master/proposals/old/Exceptions.md) - Instruction changes - Now we have one single `catch` instruction that returns a except_ref value - `throw` now can take variable number of operations - `rethrow` does not have 'depth' argument anymore - `br_on_exn` queries an except_ref to see if it matches the tag and branches to the given label if true. - `extract_exception` is a pseudo instruction that simulates popping values from wasm stack. This is to make `br_on_exn`, a very special instruction, work: `br_on_exn` puts values onto the stack only if it is taken, and the # of values can vay depending on the tag. - Now there's only one `catch` per `try`, this patch removes all special handling for terminate pad with a call to `__clang_call_terminate`. Before it was the only case there are two catch clauses (a normal `catch` and `catch_all` per `try`). - Make `rethrow` act as a terminator like `throw`. This splits BB after `rethrow` in WasmEHPrepare, and deletes an unnecessary `unreachable` after `rethrow` in LateEHPrepare. - Now we stop at all catchpads (because we add wasm `catch` instruction that catches all exceptions), this creates new `findWasmUnwindDestinations` function in SelectionDAGBuilder. - Now we use `br_on_exn` instrution to figure out if an except_ref matches the current tag or not, LateEHPrepare generates this sequence for catch pads: ``` catch block i32 br_on_exn $__cpp_exception end_block extract_exception ``` - Branch analysis for `br_on_exn` in WebAssemblyInstrInfo - Other various misc. changes to switch to the new proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D57134 llvm-svn: 352598
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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-15[WebAssembly] Fix updating/moving DBG_VALUEs in RegStackifyYury Delendik1-52/+14
Summary: As described in PR40209, there can be issues in DBG_VALUEs handling when multiple defs present in a BB. This patch adds logic for detection of related to def DBG_VALUEs and localizes register update and movement to found DBG_VALUEs. Reviewers: aheejin Subscribers: mgorny, dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D56401 llvm-svn: 351216
2019-01-10[WebAssembly] Fix stack pointer store check in RegStackifyHeejin Ahn1-13/+5
Summary: We now use __stack_pointer global and global.get/global.set instruction. This fixes the checking routine for stack_pointer writes accordingly. This also fixes the existing __stack_pointer test in reg-stackify.ll: That test used to pass not because of __stack_pointer clashes but because the function `stackpointer_callee` was not marked as `readnone`, so it was assumed to possibly write to memory arbitraily, and `global.set` instruction was marked as `mayStore` in the .td definition, so they were identified as intervening writes. After we added `readnone` to its attribute, this test fails without this patch. Reviewers: dschuff, sunfish Subscribers: jgravelle-google, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D56094 llvm-svn: 350906
2019-01-08[WebAssembly] Massive instruction renamingThomas Lively1-5/+5
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-26[WebAssembly] Delete an unnecessary line in RegStackifyHeejin Ahn1-1/+0
`OneUseInst` is set outside of the loop before and `OneUse` does not change throughout the loop, so this line is not necessary. llvm-svn: 350076
2018-12-26[WebAssembly] Fix typos in comments in RegStackify (NFC)Heejin Ahn1-2/+2
llvm-svn: 350075