aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-08-17MCSymbol: Remove setUndefinedFangrui Song1-1/+0
The name is misleading, as setting Fragment to nullptr does not necessarily make it undefined - common and equated symbols have a nullptr fragment as well.
2025-08-03MCSymbolWasm: Remove classofFangrui Song1-11/+18
The object file format specific derived classes are used in context where the type is statically known. We don't use isa/dyn_cast and we want to eliminate MCSymbol::Kind in the base class.
2025-07-26MCSectionWasm: Remove classofFangrui Song1-2/+4
The object file format specific derived classes are used in context like MCStreamer and MCObjectTargetWriter where the type is statically known. We don't use isa/dyn_cast and we want to eliminate MCSection::SectionVariant in the base class.
2025-07-07[WebAssembly,MC] Add ref.test_func handling to AsmParser (#139642)Hood Chatham1-0/+4
This will allow us to eliminate the hand-coded webassembly here: https://github.com/python/cpython/blob/main/Python/emscripten_trampoline.c#L138
2025-06-28MCParsedAsmOperand::print: Add MCAsmInfo parameterFangrui Song1-1/+1
so that subclasses can provide the appropriate MCAsmInfo to print MCExpr objects. At present, llvm/utils/TableGen/AsmMatcherEmitter.cpp constucts a generic MCAsmInfo.
2025-06-26WebAssembly: Merge MCExpr into MCAsmInfoFangrui Song1-1/+1
to align with targets that have made the transition.
2025-06-17[llvm] annotate interfaces in llvm/Target for DLL export (#143615)Andrew Rogers1-1/+3
## Purpose This patch is one in a series of code-mods that annotate LLVM’s public interface for export. This patch annotates the `llvm/Target` library. These annotations currently have no meaningful impact on the LLVM build; however, they are a prerequisite to support an LLVM Windows DLL (shared library) build. ## Background This effort is tracked in #109483. Additional context is provided in [this discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307), and documentation for `LLVM_ABI` and related annotations is found in the LLVM repo [here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst). A sub-set of these changes were generated automatically using the [Interface Definition Scanner (IDS)](https://github.com/compnerd/ids) tool, followed formatting with `git clang-format`. The bulk of this change is manual additions of `LLVM_ABI` to `LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target. Adding `LLVM_ABI` to the function implementation is required here because they do not `#include "llvm/Support/TargetSelect.h"`, which contains the declarations for this functions and was already updated with `LLVM_ABI` in a previous patch. I considered patching these files with `#include "llvm/Support/TargetSelect.h"` instead, but since TargetSelect.h is a large file with a bunch of preprocessor x-macro stuff in it I was concerned it would unnecessarily impact compile times. In addition, a number of unit tests under llvm/unittests/Target required additional dependencies to make them build correctly against the LLVM DLL on Windows using MSVC. ## Validation Local builds and tests to validate cross-platform compatibility. This included llvm, clang, and lldb on the following configurations: - Windows with MSVC - Windows with Clang - Linux with GCC - Linux with Clang - Darwin with Clang
2025-05-25MCParser: Replace deprecated alias MCAsmLexer with AsmLexerFangrui Song1-1/+1
2025-05-25Replace #include MCAsmLexer.h with AsmLexer.hFangrui Song1-1/+1
MCAsmLexer.h has been made a forwarder header since #134207
2025-04-08[WebAssembly] Add WebAssembly::SpecifierFangrui Song1-2/+3
Move wasm-specific members outside of MCSymbolRefExpr::VariantKind (a legacy interface I am eliminating). Most changes are mechanic and similar to what I've done for many ELF targets (e.g. X86 #132149) Notes: * `fixSymbolsInTLSFixups` is replaced with `setTLS` in `WebAssemblyWasmObjectWriter::getRelocType`, similar to what I've done for many ELF targets. * `SymA->setUsedInGOT()` in `recordRelocation` is moved to `getRelocType`. While here, rename "Modifier' to "Specifier": > "Relocation modifier", though concise, suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. I landed on "relocation specifier" as the winner. It's clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly. Pull Request: https://github.com/llvm/llvm-project/pull/133116
2025-03-04[lld][WebAssembly] Support for the custom-page-sizes WebAssembly proposal ↵Nick Fitzgerald1-1/+1
(#128942) This commit adds support for WebAssembly's custom-page-sizes proposal to `wasm-ld`. An overview of the proposal can be found [here](https://github.com/WebAssembly/custom-page-sizes/blob/main/proposals/custom-page-sizes/Overview.md). In a sentence, it allows customizing a Wasm memory's page size, enabling Wasm to target environments with less than 64KiB of memory (the default Wasm page size) available for Wasm memories. This commit contains the following: * Adds a `--page-size=N` CLI flag to `wasm-ld` for configuring the linked Wasm binary's linear memory's page size. * When the page size is configured to a non-default value, then the final Wasm binary will use the encodings defined in the custom-page-sizes proposal to declare the linear memory's page size. * Defines a `__wasm_first_page_end` symbol, whose address points to the first page in the Wasm linear memory, a.k.a. is the Wasm memory's page size. This allows writing code that is compatible with any page size, and doesn't require re-compiling its object code. At the same time, because it just lowers to a constant rather than a memory access or something, it enables link-time optimization. * Adds tests for these new features. r? @sbc100 cc @sunfishcode
2025-03-02[MC] Move VariantKind info to MCAsmInfoFangrui Song1-16/+0
Follow-up to 14951a5a3120e50084b3c5fb217e2d47992a24d1 * Unify getVariantKindName and getVariantKindForName * Allow each target to specify the preferred case (albeit ignored in MCParser) Note: targets that use variant kinds should call MCExpr::print with a non-null MAI to print variant kinds. operator<< passes a nullptr to `MCExpr::print`, which should be avoided (e.g. Hexagon; fixed in commit cf00ac81ac049cddb80aec1d6d88b8fab4f209e8).
2025-03-02[MCParser] Extract some VariantKind from getVariantKindForNameFangrui Song1-0/+16
All VariantKinds except VK_None/VK_Invalid are target-specific (e.g. a target may not support "@plt" even if it is widely available). Move the parsers to lib/Target to ensure that VariantKind from unrelated targets will not be parsed.
2025-02-12[MC] Replace MCContext::GenericSectionID with MCSection::NonUniqueID (#126202)Haohai Wen1-1/+1
They have same semantics. NonUniqueID is more friendly for isUnique implementation in MCSectionELF. History: 97837b7 added support for unique IDs in sections and added GenericSectionID. Later, 1dc16c7 added NonUniqueID.
2024-12-02[WebAssembly] Define call-indirect-overlong and bulk-memory-opt features ↵Dan Gohman1-7/+21
(#117087) This defines some new target features. These are subsets of existing features that reflect implementation concerns: - "call-indirect-overlong" - implied by "reference-types"; just the overlong encoding for the `call_indirect` immediate, and not the actual reference types. - "bulk-memory-opt" - implied by "bulk-memory": just `memory.copy` and `memory.fill`, and not the other instructions in the bulk-memory proposal. This is split out from https://github.com/llvm/llvm-project/pull/112035. --------- Co-authored-by: Heejin Ahn <aheejin@gmail.com>
2024-11-15[WebAssembly] Remove unused includes (NFC) (#116318)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2024-10-03[WebAssembly] Print instructions with type checking errors (#111067)Heejin Ahn1-2/+2
When there was a type checking error, we didn't run `InstPrinter`. This can be confusing because when there is an error in, say, block parameter type, `InstPrinter` doesn't run even if it has nothing to do with block parameter types, and all those updates to `ControlFlowStack` or `TryStack` do not happen: https://github.com/llvm/llvm-project/blob/c20b90ab8557b38efe8e8e993d41d8c08b798267/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyInstPrinter.cpp#L135-L151 For example, ```wast block (i32) -> () ;; Block input parameter error end_block ;; Now this errors out as "End marker mismatch" ``` This is confusing because there is a `block` and the `end_block` is not a mismatch. Only that `block` has a type checking error, but that's not an end marker mismatch. I think we can just print the instruction whether we had a type checking error or not, and this will be less confusing.
2024-10-02[WebAssembly] Handle block and polymorphic stack in AsmTypeCheck (#110770)Heejin Ahn1-2/+5
This makes the type checker handle blocks with input parameters and return types, branches, and polymorphic stacks correctly. We maintain the stack of "block info", which contains its input parameter type, return type, and whether it is a loop or not. And this is used when checking the validity of the value stack at the `end` marker and all branches targeting the block. `StackType` now supports a new variant `Polymorphic`, which indicates the stack is in the polymorphic state. `Polymorphic`s are not popped even when `popType` is executed; they are only popped when the current block ends. When popping from the value stack, we ensure we don't pop more than we are allowed to at the given block level and print appropriate error messages instead. Also after a block ends, the value stack is guaranteed to have the right types based on the block return type. For example, ```wast block i32 unreachable end_block ;; You can expect to have an i32 on the stack here ``` This also adds handling for `br_if`. Previously only `br`s were checked. `checkEnd` and `checkBr` were removed and their contents have been inlined to the main `typeCheck` function, because they are called only from a single callsite. This also fixes two existing bugs in AsmParser, which were required to make the tests passing. I added Github comments about them inline. This modifies several existing invalid tests, those that passed (incorrectly) before but do not pass with the new type checker anymore. Fixes #107524.
2024-09-26[WebAssembly] Unify type checking in AsmTypeCheck (#110094)Heejin Ahn1-1/+1
This unifies the way we check types in various places in AsmTypeCheck. The objectives of this PR are: - We now use `checkTypes` for all type checking and `checkAndPopTypes` for type checking + popping. All other functions are helper functions to call these two functions. - We now support comparisons of types between vectors. This lets us printing error messages in more readable way. When an instruction takes [i32, i64] but the stack top is [f32, f64], now instead of ```console error: type mismatch, expected i64 but got f64 error: type mismatch, expected i32 but got f32 ``` we can print this ```console error: type mismatch, expected [i32, i64] but got [f32, f64] ``` which is also the format Wabt checker prints. This also helps printing more meaningful messages when there are superfluous values on the stack at the end of the function, such as: ```console error: type mismatch, expected [] but got [i32, exnref] ``` Actually, many instructions are not utilizing this batch printing now, which still causes multiple error messages to be printed for a single instruction. This will be improved in a follow-up. - The value stack now supports `Any` and `Ref`. There are instructions that requires the type to be anything. Also instructions like `ref.is_null` requires the type to be any reference types. Type comparison function will handle this types accordingly, meaning `match(I32, Any)` or `match(externref, Ref)` will succeed. The changes in `type-checker-errors.s` are mostly the message format changes. One downside of the new message format is that it doesn't have instruction names in it. I plan to improve that in a potential follow-up. This also made some modifications in the instructions in `type-checker-errors.s`. Currently, except for a few functions I've recently added at the end, each function tests for a single error, because the type checker used to bail out after the first error until #109705. But many functions included multiple errors anyway, which I don't think was the intention of the original writer. So I added some instructions to remove the other errors which are not being tested. (In some cases I added more error checking lines instead, when I felt that could be relevant.) Thanks to the new `ExactMatch` option in `checkTypes` function family, we now can distinguish the cases when to check against only the top of the value stack and when to check against the whole stack (e.g. to check whether we have any superfluous values remaining at the end of the function). `return` or `return_call(_indirect)` can set `ExactMatch` to `false` because they don't care about the superfluous values. This makes `type-checker-return.s` succeed and I was able to remove the `FIXME`. This is the basis of the PR that fixes block parameter/return type handling in the checker, but does not yet include the actual block-related functionality, which will be submitted separately after this PR.
2024-09-23[WebAssembly] Apply clang-tidy fixes on AsmParser/TypeCheck (NFC) (#109692)Heejin Ahn1-48/+46
Fixes are mostly one of these: - `auto` -> `auto *` when the type is a pointer - Function names start with a lowercase letter - Variable names start with an uppercase letter - No need to have an `else` after a `return` Diff without whitespaces is easier to view.
2024-09-18[NFC] Update function names in MCTargetAsmParser.h (#108643)Lei Huang1-2/+2
Update function names to adhere to LLVM coding standard.
2024-09-17[WebAssembly] Support assembly parsing for new EH (#108668)Heejin Ahn1-10/+137
This adds assembly parsing support for the new EH (exnref) proposal. `try_table` parsing is a little tricky because catch clause lists use `()` and the multivalue block return types also use `()`. This handles all combinations below: - No return type (void) + no catch list - No return type (void) + catch list - Single return type + no catch list - Single return type + catch list - Multivalue return type + no catch list - Multivalue return type + catch list This does not include AsmTypeCheck support yet. That's the reason why this adds a new test file and use `--no-type-check` in the command line. After the type checker is added as a follow-up, I plan to merge https://github.com/llvm/llvm-project/blob/main/llvm/test/MC/WebAssembly/eh-assembly-legacy.s with this file. (Turning on `-mattr=+exception-handling` adds support for all legacy and new EH instructions in the assembly. `-wasm-enable-exnref` in `llc` only controls which instructions to generate and it doesn't affect `llvm-mc` and assembly parsing.)
2024-09-10[WebAssembly] Add assembly support for final EH proposal (#107917)Heejin Ahn1-1/+9
This adds the basic assembly generation support for the final EH proposal, which was newly adopted in Sep 2023 and advanced into Phase 4 in Jul 2024: https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md This adds support for the generation of new `try_table` and `throw_ref` instruction in .s asesmbly format. This does NOT yet include - Block annotation comment generation for .s format - .o object file generation - .s assembly parsing - Type checking (AsmTypeCheck) - Disassembler - Fixing unwind mismatches in CFGStackify These will be added as follow-up PRs. --- The format for `TRY_TABLE`, both for `MachineInstr` and `MCInst`, is as follows: ``` TRY_TABLE type number_of_catches catch_clauses* ``` where `catch_clause` is ``` catch_opcode tag+ destination ``` `catch_opcode` should be one of 0/1/2/3, which denotes `CATCH`/`CATCH_REF`/`CATCH_ALL`/`CATCH_ALL_REF` respectively. (See `BinaryFormat/Wasm.h`) `tag` exists when the catch is one of `CATCH` or `CATCH_REF`. The MIR format is printed as just the list of raw operands. The (stack-based) assembly instruction supports pretty-printing, including printing `catch` clauses by name, in InstPrinter. In addition to the new instructions `TRY_TABLE` and `THROW_REF`, this adds four pseudo instructions: `CATCH`, `CATCH_REF`, `CATCH_ALL`, and `CATCH_ALL_REF`. These are pseudo instructions to simulate block return values of `catch`, `catch_ref`, `catch_all`, `catch_all_ref` clauses in `try_table` respectively, given that we don't support block return values except for one case (`fixEndsAtEndOfFunction` in CFGStackify). These will be omitted when we lower the instructions to `MCInst` at the end. LateEHPrepare now will have one more stage to covert `CATCH`/`CATCH_ALL`s to `CATCH_REF`/`CATCH_ALL_REF`s when there is a `RETHROW` to rethrow its exception. The pass also converts `RETHROW`s into `THROW_REF`. Note that we still use `RETHROW` as an interim pseudo instruction until we convert them to `THROW_REF` in LateEHPrepare. CFGStackify has a new `placeTryTableMarker` function, which places `try_table`/`end_try_table` markers with a necessary `catch` clause and also `block`/`end_block` markers for the destination of the `catch` clause. In MCInstLower, now we need to support one more case for the multivalue block signature (`catch_ref`'s destination's `(i32, exnref)` return type). InstPrinter has a new routine to print the `catch_list` type, which is used to print `try_table` instructions. The new test, `exception.ll`'s source is the same as `exception-legacy.ll`, with the FileCheck expectations changed. One difference is the commands in this file have `-wasm-enable-exnref` to test the new format, and don't have `-wasm-disable-explicit-locals -wasm-keep-registers`, because the new custom InstPrinter routine to print `catch_list` only works for the stack-based instructions (`_S`), and we can't use `-wasm-keep-registers` for them. As in `exception-legacy.ll`, the FileCheck lines for the new tests do not contain the whole program; they mostly contain only the control flow instructions for readability.
2024-09-03[WebAssembly] Remove Kind argument from WebAssemblyOperand (NFC) (#107157)Heejin Ahn1-33/+23
The `Kind` argument does not need to passed separately.
2024-06-29[MC] getWasmSection: remove unused BeginSymNameFangrui Song1-3/+2
This is cargo culting for Mach-O. See #96810
2024-06-28[MC] Replace getCurrentSection().first with getCurrentSectionOnly. NFCFangrui Song1-3/+3
2024-06-20[MC] Remove SectionKind from MCSection (#96067)aengelke1-2/+2
There are only three actual uses of the section kind in MCSection: isText(), XCOFF, and WebAssembly. Store isText() in the MCSection, and store other info in the actual section variants where required. ELF and COFF flags also encode all relevant information, so for these two section variants, remove the SectionKind parameter entirely. This allows to remove the string switch (which is unnecessary and inaccurate) from createELFSectionImpl. This was introduced in [D133456](https://reviews.llvm.org/D133456), but apparently, it was never hit for non-writable sections anyway and the resulting kind was never used.
2024-06-05[WebAssembly] Set IS_64 flag correctly on __indirect_function_table in ↵Sam Clegg1-4/+8
object files (#94487) Follow up to #92042
2024-04-02[WebAssembly] Allocate MCSymbolWasm data on MCContext (#85866)Tim Neumann1-31/+14
Fixes #85578, a use-after-free caused by some `MCSymbolWasm` data being freed too early. Previously, `WebAssemblyAsmParser` owned the data that is moved to `MCContext` by this PR, which caused problems when handling module ASM, because the ASM parser was destroyed after parsing the module ASM, but the symbols persisted. The added test passes locally with an LLVM build with AddressSanitizer enabled. Implementation notes: * I've called the added method <code>allocate<b><i>Generic</i></b>String</code> and added the second paragraph of its documentation to maybe guide people a bit on when to use this method (based on my (limited) understanding of the `MCContext` class). We could also just call it `allocateString` and remove that second paragraph. * The added `createWasmSignature` method does not support taking the return and parameter types as arguments: Specifying them afterwards is barely any longer and prevents them from being accidentally specified in the wrong order. * This removes a _"TODO: Do the uniquing of Signatures here instead of ObjectFileWriter?"_ since the field it's attached to is also removed. Let me know if you think that TODO should be preserved somewhere.
2024-03-25[MC] Make `MCParsedAsmOperand::getReg()` return `MCRegister` (#86444)Sergei Barannikov1-1/+1
2024-01-17[WebAssembly] Use ValType instead of integer types to model wasm tables (#78012)Derek Schuff1-1/+1
LLVM models some features found in the binary format with raw integers and others with nested or enumerated types. This PR switches modeling of tables and segments to use wasm::ValType rather than uint32_t. This NFC change is in preparation for modeling more reference types, but IMO is also cleaner and closer to the spec.
2023-12-11[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)Kazu Hirata1-1/+1
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-11-01[llvm] Stop including llvm/Support/Endian.h (NFC)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2023-09-06[MC] Change tryParseRegister to return ParseStatus (NFC)Sergei Barannikov1-5/+3
This finishes the work of replacing OperandMatchResultTy with ParseStatus, started in D154101. As a drive-by change, rename some RegNo variables to just Reg (a leftover from the days when RegNo had 'unsigned' type).
2023-07-01[MC] Add three-state parseDirective as a replacement for ParseDirectiveSergei Barannikov1-31/+34
Conventionally, parsing methods return false on success and true on error. However, directive parsing methods need a third state: the directive is not target specific. AsmParser::parseStatement detected this case by using a fragile heuristic: if the target parser did not consume any tokens, the directive is assumed to be not target-specific. Some targets fail to follow the convention: they return success after emitting an error or do not consume the entire line and return failure on successful parsing. This was partially worked around by checking for pending errors in parseStatement. This patch tries to improve the situation by introducing parseDirective method that returns ParseStatus -- three-state class. The new method should eventually replace the old one returning bool. ParseStatus is intentionally implicitly constructible from bool to allow uses like `return Error(Loc, "message")`. It also has a potential to replace OperandMatchResulTy as it is more convenient to use due to the implicit construction from bool and more type safe. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D154101
2023-04-11[NFC] format llvm/lib/Target/WebAssembly/AsmParserCongcong Cai1-6/+7
Reviewed By: aheejin Differential Revision: https://reviews.llvm.org/D147884
2023-04-11[WebAssembly] Correctly check end_if/end_try with else/catchHeejin Ahn1-7/+19
When we encounter an `else`, `catch`, or `catch_all`, we currently just push the structure `NestingType` and don't preserve the original `if` and `try`'s signature. So after we pass `else`/`catch`/`catch_all`, we can't check if the values on stack have the correct types when we encounter `end_if` or `end_try`. This CL fixes the issue, and modifies the existing test to be correct (some of them had `try` without `catch`). Reviewed By: dschuff Differential Revision: https://reviews.llvm.org/D147881
2023-04-11[WebAssembly] Fix type index block type handling in type checkerHeejin Ahn1-1/+1
The current code is ``` ExpectBlockType = false; TC.setLastSig(*Signature.get()); if (ExpectBlockType) NestingStack.back().Sig = *Signature.get(); ``` Because of the first line, the third line's `if (ExpectBlockType)` is always false and we don't get to update `NestingStack.back().Sig`. This results in not correctly erroring out when the types of remaining values on the stack do not match the block type if the block type is written in the form of a function type. We should set `ExpectBlockType` to false after the `if`. Reviewed By: sbc100 Differential Revision: https://reviews.llvm.org/D147837
2023-02-23[WebAssembly] Split WebAssemblyUtils to fix library layering for MC tools.Craig Topper1-2/+1
WebAssemblyUtils depends on CodeGen which depends on all middle end optimization libraries. This component is used by WebAssembly's AsmParser, Disassembler, and MCTargetDesc libraries. Because of this, any MC layer tool built with WebAssembly support includes a larger portion of LLVM than it should. To fix this I've created an MC only version of WebAssemblyTypeUtilities.cpp in MCTargetDesc to be used by the MC components. This shrinks llvm-objdump and llvm-mc on my local release+asserts build by 5-6 MB. Reviewed By: MaskRay, aheejin Differential Revision: https://reviews.llvm.org/D144354
2023-01-09[WebAssembly] Ensure 'end_function' in functionsHeejin Ahn1-8/+38
Local info is supposed to be emitted in the start of every function. When there are locals, `.local` section should be present, and we emit local info according to the section. If there is no locals, empty local info should be emitted. This empty local info is emitted whenever a first instruction is emitted within a function without encountering a `.local` section. If there is no instruction, `end_function` pseudo instruction should be present and the empty local info will be emitted when parsing the pseudo instruction. The following assembly is malformed because the function `test` doesn't have an `end_function` at the end, and the parser doesn't end up emitting the empty local info needed. But currently we don't error out and silently produce an invalid binary. ``` .functype test () -> () test: ``` This patch adds one extra state to the Wasm assembly parser, `FunctionLabel` to detect whether a function label is parsed but not ended properly when the next function starts or the file ends. It is somewhat tricky to distinguish `FunctionLabel` and `FunctionStart`, because it is not always possible to ensure the state goes from `FunctionLabel` -> `FunctionStart`. `.functype` directive does not seem to be mandated before a function label, in which case we don't know if the label is a function at the time of parsing. But when we do know the label is function, we would like to ensure it ends with an `end_function` properly. Also we would like to error out when it does not. For example, ``` .functype test() -> () test: ``` We should error out for this because we know `test` is a function and it doesn't end with an `end_function`. This PR fixes this. ``` test: ``` We don't error out for this because there is no info that `test` is a function, so we don't know whether there should be an `end_function` or not. ``` test: .functype test() -> () ``` We error out for this currently already, because we currently switch to `FunctionStart` state when we first see `.functype` directive after its label definition. Fixes https://github.com/llvm/llvm-project/issues/57427. Reviewed By: sbc100 Differential Revision: https://reviews.llvm.org/D141103
2022-12-18[MC] Use `MCRegister` instead of `unsigned` in `MCTargetAsmParser`Sergei Barannikov1-3/+3
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D140273
2022-12-04[Target] llvm::Optional => std::optionalFangrui Song1-1/+2
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-09-01[MC][WebAssembly] Allow accurate errors in doBeforeLabelEmitSam Clegg1-2/+2
Although we only currently have one error produced in this function I am working on changes right now that add some more. This change makes the error location more accurate. Differential Revision: https://reviews.llvm.org/D133016
2022-08-31[WebAssembly][MC] Avoid the need for .size directives for functionsSam Clegg1-11/+0
Warn if `.size` is specified for a function symbol. The size of a function symbol is determined solely by its content. I noticed this simplification was possible while debugging #57427, but this change doesn't fix that specific issue. Differential Revision: https://reviews.llvm.org/D132929
2022-06-20[llvm] Don't use Optional::getValue (NFC)Kazu Hirata1-4/+3
2022-06-10[MC] De-capitalize SwitchSection. NFCFangrui Song1-1/+1
Add SwitchSection to return switchSection. The API will be removed soon.
2022-05-19[WebAssembly] Fix bug where -no-type-check failed to completely disable the ↵Alex Bradbury1-1/+2
typechecker Related to <https://github.com/llvm/llvm-project/issues/55566>. Committing directly (per LLVM's code review policy) as this is a trivial fix.
2022-03-23[WebAssembly] Fix error location for parsed symbol/label operandsAlex Bradbury1-1/+2
The previous code didn't take account for the fact that parseExpression my lex additional tokens - because of this, it's necessary to record the location of the current token ahead of the call. This patch additionally makes use of the fact parseExpression will set its End parameter to the end of the expression. Although this fix could be added independently of D122127, I've opted to make it a child patch in order to ensure the change has some test coverage. Differential Revision: https://reviews.llvm.org/D122128
2022-03-23[WebAssembly] Use location of operand for operand-based type check errorsAlex Bradbury1-1/+1
This addresses a series of FIXMEs introduced in D122020. A follow-up patch (D122128) addresses the bug that is exposed by this change (an issue with source location information when lexing identifiers). Differential Revision: https://reviews.llvm.org/D122127
2022-02-11Cleanup MCParser headersserge-sans-paille1-0/+1
As usual with that header cleanup series, some implicit dependencies now need to be explicit: llvm/MC/MCParser/MCAsmParser.h no longer includes llvm/MC/MCParser/MCAsmLexer.h Preprocessed lines to build llvm on my setup: after: 1068185081 before: 1068324320 So no compile time benefit to expect, but we still get the looser coupling between files which is great. Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D119359