summaryrefslogtreecommitdiff
path: root/llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.cpp
AgeCommit message (Collapse)Author
2025-10-29[WebAssembly] Remove a redundant cast (NFC) (#165508)Kazu Hirata
Local is already of type unsigned.
2025-09-12CodeGen: Remove MachineFunction argument from getPointerRegClass (#158185)Matt Arsenault
getPointerRegClass is a layering violation. Its primary purpose is to determine how to interpret an MCInstrDesc's operands RegClass fields. This should be context free, and only depend on the subtarget. The model of this is also wrong, since this should be an instruction / operand specific property, not a global pointer class. Remove the the function argument to help stage removal of this hook and avoid introducing any new obstacles to replacing it. The remaining uses of the function were to get the subtarget, which TargetRegisterInfo already belongs to. A few targets needed new subtarget derived properties copied there.
2024-11-15[WebAssembly] Remove unused includes (NFC) (#116318)Kazu Hirata
Identified with misc-include-cleaner.
2024-10-18[llvm] Consistently respect `naked` fn attribute in ↵Alex Rønne Petersen
`TargetFrameLowering::hasFP()` (#106014) Some targets (e.g. PPC and Hexagon) already did this. I think it's best to do this consistently so that frontend authors don't run into inconsistent results when they emit `naked` functions. For example, in Zig, we had to change our emit code to also set `frame-pointer=none` to get reliable results across targets. Note: I don't have commit access.
2023-10-03[WebAssembly] Define local sp if `llvm.stacksave` is used (#68133)Yuta Saito
Usually `llvm.stacksave/stackrestore` are used together with `alloca` but they can appear without it (e.g. `alloca` can be optimized away). WebAssembly's function local physical user sp register, which is referenced by `llvm.stacksave` is created while frame lowering and replaced with virtual register. However the sp register was not created when `llvm.stacksave` is used without `alloca`, and it led MIR verification failure about use-before-def of sp virtual register. Resolves https://github.com/llvm/llvm-project/issues/62235
2022-12-04[Target] llvm::Optional => std::optionalFangrui Song
The updated functions are mostly internal with a few exceptions (virtual functions in TargetInstrInfo.h, TargetRegisterInfo.h). To minimize changes to LLVMCodeGen, GlobalISel files are skipped. https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[Target] Use std::nullopt instead of None (NFC)Kazu Hirata
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-08-01[NFC] Use AllocaInst's getAddressSpace helperAlex Bradbury
2022-01-29[WebAssembly][NFC] Refactor WasmSymbol type setting codePaulo Matos
This refactors some code dealing with setting Wasm symbol types. Some of the code dealing with types was moved from `WebAssemblyUtilities` to `WebAssemblyTypeUtilities`. Reviewed By: sbc100 Differential Revision: https://reviews.llvm.org/D118121
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-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-03-30[NFC][CodeGen] Tidy up TargetRegisterInfo stack realignment functionsTomas Matheson
Currently needsStackRealignment returns false if canRealignStack returns false. This means that the behavior of needsStackRealignment does not correspond to it's name and description; a function might need stack realignment, but if it is not possible then this function returns false. Furthermore, needsStackRealignment is not virtual and therefore some backends have made use of canRealignStack to indicate whether a function needs stack realignment. This patch attempts to clarify the situation by separating them and introducing new names: - shouldRealignStack - true if there is any reason the stack should be realigned - canRealignStack - true if we are still able to realign the stack (e.g. we can still reserve/have reserved a frame pointer) - hasStackRealignment = shouldRealignStack && canRealignStack (not target customisable) Targets can now override shouldRealignStack to indicate that stack realignment is required. This change will make it easier in a future change to handle the case where we need to realign the stack but can't do so (for example when the register allocator creates an aligned spill after the frame pointer has been eliminated). Differential Revision: https://reviews.llvm.org/D98716 Change-Id: Ib9a4d21728bf9d08a545b4365418d3ffe1af4d87
2020-06-25[WebAssembly] Adding 64-bit versions of __stack_pointer and other globalsWouter van Oortmerssen
We have 6 globals, all of which except for __table_base are 64-bit under wasm64. Differential Revision: https://reviews.llvm.org/D82130
2020-04-16[WebAssembly] Add int32 DW_OP_WASM_location variantWouter van Oortmerssen
This to allow us to add reloctable global indices as a symbol. Also adds R_WASM_GLOBAL_INDEX_I32 relocation type to support it. See discussion in https://github.com/WebAssembly/debugging/issues/12
2020-03-18[Alignment][NFC] Deprecate getMaxAlignmentGuillaume Chatelet
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, arsenm, dschuff, jyknight, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76348
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-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-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-04-03[WebAssembly] Remove unneeded target operand flagsSam Clegg
This change is in preparation for the addition of new target operand flags for new relocation types. Have a symbol type as part of the flag set makes it harder to use and AFAICT these are serving no purpose. Differential Revision: https://reviews.llvm.org/D60014 llvm-svn: 357548
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-09-05[WebAssembly] clang-format (NFC)Heejin Ahn
Summary: This patch runs clang-format on all wasm-only files. Reviewers: aardappel, dschuff, sunfish, tlively Subscribers: MatzeB, sbc100, jgravelle-google, llvm-commits Differential Revision: https://reviews.llvm.org/D51447 llvm-svn: 341439
2018-08-22[WebAssembly] Don't write SP back when prolog is generated only for EHHeejin Ahn
Summary: When we don't actually have stack-allocated variables but need SP only to support EH, we don't need to write SP back in the epilog, because we don't bump down the stack pointer. Reviewers: dschuff Subscribers: jgravelle-google, sbc100, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51114 llvm-svn: 340454
2018-08-22[WebAssembly] Remove MachineFrameInfo arg from checking functions (NFC)Heejin Ahn
Summary: There are several functions in the form of `has***` or `needs***` in `WebAssemblyFrameLowering` and its `MachineFrameInfo` argument can be obtained from `MachineFunction` so it is not necessarily has to be passed from a caller. Also, it is more in line with other overriden fuctions like `hasBP` or `hasReservedCallFrame`, which also take only `MachineFunction` argument. Reviewers: dschuff Subscribers: sbc100, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51116 llvm-svn: 340438
2018-08-22[WebAssembly] Change comments on SP writing back (NFC)Heejin Ahn
Summary: We now write back not to memory but to __stack_pointer global. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51074 llvm-svn: 340372
2018-08-21[WebAssembly] Restore __stack_pointer after catch instructionsHeejin Ahn
Summary: After the stack is unwound due to a thrown exception, the `__stack_pointer` global can point to an invalid address. This inserts instructions that restore `__stack_pointer` global. Reviewers: jgravelle-google, dschuff Subscribers: mgorny, sbc100, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D50980 llvm-svn: 340339
2018-08-21[WebAssembly] Change writeSPToMemory to writeSPToGlobal (NFC)Heejin Ahn
Summary: SP is now a __stack_pointer global and not a memory address anymore. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51046 llvm-svn: 340328
2018-08-20[WebAssembly] Remove an unused argument from writeSPToMemory (NFC)Heejin Ahn
Reviewers: dschuff Subscribers: dschuff, sbc100, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D50933 llvm-svn: 340230
2018-08-03[WebAssembly] Cleanup of the way globals and global flags are handledNicholas Wilson
Differential Revision: https://reviews.llvm.org/D44030 llvm-svn: 338894
2018-07-16[WebAssembly] Remove ELF file support.Sam Clegg
This support was partial and temporary. Now that we have wasm object file support its no longer needed. Differential Revision: https://reviews.llvm.org/D48744 llvm-svn: 337222
2018-05-01Remove \brief commands from doxygen comments.Adrian Prantl
We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2017-12-15Fix WebAssembly backend for some LLVM API changesDavid Blaikie
llvm-svn: 320893
2017-06-16[WebAssembly] Use __stack_pointer global when writing wasm binarySam Clegg
This ensures that symbolic relocations are generated for stack pointer manipulations. These relocations are of type R_WEBASSEMBLY_GLOBAL_INDEX_LEB. This change also adds support for reading relocations of this type in WasmObjectFile.cpp. Since its a globally imported symbol this does mean that the get_global/set_global instruction won't be valid until the objects are linked that global used in no longer an imported global. Differential Revision: https://reviews.llvm.org/D34172 llvm-svn: 305616
2017-03-30[WebAssembly] Initial linking metadata supportDan Gohman
Add support for the new relocations and linking metadata section support in https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md. In particular, this allows LLVM to indicate which variable is the stack pointer, so that it can be linked with other objects. This also adds support for emitting type relocations for call_indirect instructions. Right now, this is mainly tested by using wabt and hexdump to examine the output on selected testcases. We'll add more tests as the design stablizes and more of the pieces are in place. llvm-svn: 299141
2017-02-24[WebAssembly] Add support for using a wasm global for the stack pointer.Dan Gohman
This replaces the __stack_pointer variable which was allocated in linear memory. llvm-svn: 296201
2017-02-24[WebAssembly] Basic support for Wasm object file encoding.Dan Gohman
With the "wasm32-unknown-unknown-wasm" triple, this allows writing out simple wasm object files, and is another step in a larger series toward migrating from ELF to general wasm object support. Note that this code and the binary format itself is still experimental. llvm-svn: 296190
2016-12-02[WebAssembly] Fix a compiler warning. NFC.Dan Gohman
Fix a warning about a comparison between signed and unsigned integer expressions. llvm-svn: 288532
2016-11-07[WebAssembly] Emit a BasePointer when we have overly-aligned stack objectsDerek Schuff
Because we shift the stack pointer by an unknown amount, we need an additional pointer. In the case where we have variable-size objects as well, we can't reuse the frame pointer, thus three pointers. Patch by Jacob Gravelle Differential Revision: https://reviews.llvm.org/D26263 llvm-svn: 286160
2016-10-25[WebAssembly] Reorder load/store operands to match binary encoding.Dan Gohman
The p2align operand of a load/store is encoded before the offset operand; reorder the MachineInstr operands accordingly. llvm-svn: 285044
2016-10-06[WebAssembly] Remove the output operand from stores.Dan Gohman
Per spec changes, store instructions in WebAssembly no longer have a return value. Update the instruction descriptions. Differential Revision: https://reviews.llvm.org/D25122 llvm-svn: 283501
2016-08-12[WebAssembly] Plug MachineMemOperand leaks.Benjamin Kramer
llvm-svn: 278545
2016-07-28MachineFunction: Return reference for getFrameInfo(); NFCMatthias Braun
getFrameInfo() never returns nullptr so we should use a reference instead of a pointer. llvm-svn: 277017
2016-06-12Pass DebugLoc and SDLoc by const ref.Benjamin Kramer
This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512