|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
e0e687a6 |
| 20-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
59726668 |
| 20-May-2022 |
Dan Gohman <[email protected]> |
[WebAssembly] Strip TLS when "atomics" is not enabled
With f3b4f99007cdcb3306484c9a39d31addc20aaa69, the exclusive source of truth for whether threads are supported is the -matomics flag. Accordingl
[WebAssembly] Strip TLS when "atomics" is not enabled
With f3b4f99007cdcb3306484c9a39d31addc20aaa69, the exclusive source of truth for whether threads are supported is the -matomics flag. Accordingly, strip TLS flags when -matomic is not specified, even if bulk-memory is specified and it would theoretically be supportable. This allows the backend to compile TLS variables when -mbulk-memory is enabled but threads are not enabled.
Differential Revision: https://reviews.llvm.org/D125730
show more ...
|
| #
cde083e0 |
| 13-May-2022 |
Heejin Ahn <[email protected]> |
[WebAssembly] Fix register use-def in FixIrreducibleControlFlow
FixIrreducibleControlFlow pass adds dispatch blocks with a `br_table` that has multiple predecessors and successors, because it serves
[WebAssembly] Fix register use-def in FixIrreducibleControlFlow
FixIrreducibleControlFlow pass adds dispatch blocks with a `br_table` that has multiple predecessors and successors, because it serves as something like a traffic hub for BBs. As a result of this, there can be register uses that are not dominated by a def in every path from the entry block. For example, suppose register %a is defined in BB1 and used in BB2, and there is a single path from BB1 and BB2: ``` BB1 -> ... -> BB2 ``` After FixIrreducibleControlFlow runs, there can be a dispatch block between these two BBs: ``` BB1 -> ... -> Dispatch -> ... -> BB2 ``` And this dispatch block has multiple predecessors, now there is a path to BB2 that does not first visit BB1, and in that path %a is not dominated by a def anymore.
To fix this problem, we have been adding `IMPLICIT_DEF`s to all registers in PrepareForLiveInternals pass, and then remove unnecessary ones in OptimizeLiveIntervals pass after computing `LiveIntervals`. But FixIrreducibleControlFlow pass itself ends up violating register use-def relationship, resulting in invalid code. This was OK so far because MIR verifier apparently didn't check this in validation. But @arsenm fixed this and it caught this bug in validation (https://github.com/llvm/llvm-project/issues/55249).
This CL moves the `IMPLICIT_DEF` adding routine from PrepareForLiveInternals to FixIrreducibleControlFlow. We only run it when FixIrreducibleControlFlow changes the code. And then PrepareForLiveInternals doesn't do anything other than setting `TracksLiveness` property, which is a prerequisite for running `LiveIntervals` analysis, which is required by the next pass OptimizeLiveIntervals.
But in our backend we don't seem to do anything that invalidates this up until OptimizeLiveIntervals, and I'm not sure why we are calling `invalidateLiveness` in ReplacePhysRegs pass, because what that pass does is to replace physical registers with virtual ones 1-to-1. I deleted the `invalidateLiveness` call there and we don't need to set that flag explicitly, which obviates all the need for PrepareForLiveInternals.
(By the way, This 'Liveness' here is different from `LiveIntervals` analysis. Setting this only means BBs' live-in info is correct, all uses are dominated by defs, `kill` flag is conservatively correct, which means if there is a `kill` flag set it should be the last use. See https://github.com/llvm/llvm-project/blob/2a0837aab1489c88efb03784e34c4dc9f2e28302/llvm/include/llvm/CodeGen/MachineFunction.h#L125-L134 for details.)
So this CL removes PrepareForLiveInternals pass altogether. Something similar to this was attempted by D56091 long ago but that came short of actually removing the pass, and I couldn't land it because FixIrreducibleControlFlow violated use-def relationship, which this CL fixes.
This doesn't change output in any meaningful way. All test changes except `irreducible-cfg.mir` are register numbering.
Also this will likely to reduce compilation time, because we have been adding `IMPLICIT_DEF` for all registers every time `-O2` is given, but now we do that only when there is irreducible control flow, which is rare.
Fixes https://github.com/llvm/llvm-project/issues/55249.
Reviewed By: dschuff, kripken
Differential Revision: https://reviews.llvm.org/D125515
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
39f15686 |
| 05-Apr-2022 |
Matt Arsenault <[email protected]> |
Transforms: Split LowerAtomics into separate Utils and pass
This will allow code sharing from AtomicExpandPass. Not entirely sure why these exist as separate passes though.
|
| #
1235aaef |
| 06-Apr-2022 |
Craig Topper <[email protected]> |
[AArch64][AMDGPU][WebAssembly] Use static_cast instead of a reinterpret_cast to downcast in parseMachineFunctionInfo. NFC
static_cast is a little safer here since the compiler will ensure we're cast
[AArch64][AMDGPU][WebAssembly] Use static_cast instead of a reinterpret_cast to downcast in parseMachineFunctionInfo. NFC
static_cast is a little safer here since the compiler will ensure we're casting to a class derived from yaml::MachineFunctionInfo.
I believe this first appeared on AMDGPU and was copied to the other two targets.
Spotted when it was being copied to RISCV in D123178.
Differential Revision: https://reviews.llvm.org/D123260
show more ...
|
| #
64902d33 |
| 24-Mar-2022 |
Julian Lettner <[email protected]> |
Reland "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_te
Reland "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.
Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this.
Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future.
Differential Revision: https://reviews.llvm.org/D121736
show more ...
|
| #
581dc3c7 |
| 23-Mar-2022 |
Zequan Wu <[email protected]> |
Revert "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
This reverts commit 22570bac694396514fff18dec926558951643fa6.
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
22570bac |
| 09-Mar-2022 |
Julian Lettner <[email protected]> |
Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.
Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.
Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this.
Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future.
Differential Revision: https://reviews.llvm.org/D121736
show more ...
|
| #
7262eacd |
| 15-Mar-2022 |
Simon Pilgrim <[email protected]> |
Revert rG9c542a5a4e1ba36c24e48185712779df52b7f7a6 "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
Mane of the build bots are complaining: Unknown command line argument '-lower-global-dtor
Revert rG9c542a5a4e1ba36c24e48185712779df52b7f7a6 "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
Mane of the build bots are complaining: Unknown command line argument '-lower-global-dtors'
show more ...
|
| #
9c542a5a |
| 09-Mar-2022 |
Julian Lettner <[email protected]> |
Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.
Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.
Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this.
Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future.
Differential Revision: https://reviews.llvm.org/D121327
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2 |
|
| #
c4b1a63a |
| 25-Feb-2022 |
Jameson Nash <[email protected]> |
mark getTargetTransformInfo and getTargetIRAnalysis as const
Seems like this can be const, since Passes shouldn't modify it.
Reviewed By: wsmoses
Differential Revision: https://reviews.llvm.org/D1
mark getTargetTransformInfo and getTargetIRAnalysis as const
Seems like this can be const, since Passes shouldn't modify it.
Reviewed By: wsmoses
Differential Revision: https://reviews.llvm.org/D120518
show more ...
|
| #
4f9b8397 |
| 17-Feb-2022 |
Heejin Ahn <[email protected]> |
[WebAssembly] Make EH/SjLj vars unconditionally thread local
This makes three thread local variables (`__THREW__`, `__threwValue`, and `__wasm_lpad_context`) unconditionally thread local. If the tar
[WebAssembly] Make EH/SjLj vars unconditionally thread local
This makes three thread local variables (`__THREW__`, `__threwValue`, and `__wasm_lpad_context`) unconditionally thread local. If the target doesn't support TLS, they will be downgraded to normal variables in `stripThreadLocals`. This makes the object not linkable with other objects using shared memory, which is what we intend here; these variables should be thread local when used with shared memory. This is what we initially tried in D88262.
But D88323 changed this: It only created these variables when threads were supported, because `__THREW__` and `__threwValue` were always generated even if Emscripten EH/SjLj was not used, making all objects built without threads not linkable with shared memory, which was too restrictive. But sometimes this is not safe. If we build an object using variables such as `__THREW__` without threads, it can be linked to other objects using shared memory, because the original object's `__THREW__` was not created thread local to begin with.
So this CL basically reverts D88323 with some additional improvements: - This checks each of the functions and global variables created within `LowerEmscriptenEHSjLj` pass and removes it if it's not used at the end of the pass. So only modules using those variables will be affected. - Moves `CoalesceFeaturesAndStripAtomics` and `AtomicExpand` passes after all other IR pasess that can create thread local variables. It is not sufficient to move them to the end of `addIRPasses`, because `__wasm_lpad_context` is created in `WasmEHPrepare`, which runs inside `addPassesToHandleExceptions`, which runs before `addISelPrepare`. So we override `addISelPrepare` and move atomic/TLS stripping and expanding passes there.
This also removes merges `TLS` and `NO-TLS` FileCheck lines into one `CHECK` line, because in the bitcode level we always create them as thread local. Also some function declarations are deleted `CHECK` lines because they are unused.
Reviewed By: tlively, sbc100
Differential Revision: https://reviews.llvm.org/D120013
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
4625b848 |
| 16-Dec-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Support clang -fwasm-exceptions for bitcode
This supports bitcode compilation using `clang -fwasm-exceptions`.
---
The current situation:
Currently the backend requires two options
[WebAssembly] Support clang -fwasm-exceptions for bitcode
This supports bitcode compilation using `clang -fwasm-exceptions`.
---
The current situation:
Currently the backend requires two options for Wasm EH: `-wasm-enable-eh` and `-exception-model=wasm`. Wasm SjLj requires two options as well: `-wasm-enable-sjlj` and `-exception-model=wasm`. When using Wasm EH via Emscripten, you only need to pass `-fwasm-exceptions`, and these options will be added within the clang driver. This description will focus on the case of Wasm EH going forward, but Wasm SjLj's case is similar.
When you pass `-fwasm-exceptions` to emcc and clang driver, the clang driver adds these options to the command line that calls the clang frontend (`clang -cc1`): `-mllvm -wasm-enable-eh` and `-exception-model=wasm`. `-wasm-enable-eh` is prefixed with `-mllvm`, so it is passed as is to the backend. But `-exception-model` is parsed and processed within the clang frontend and stored in `LangOptions` class. This info is later transferred to `TargetOptions` class, and then eventually passed to `MCAsmInfo` class. All LLVM code queries this `MCAsmInfo` to get the exception model.
---
Problem:
The problem is the whole `LangOptions` processing is bypassed when compiling bitcode, so the information transfer of `LangOptions` -> `TargetOptions` -> `MCAsmInfo` does not happen. They are all set to `ExceptionHandling::None`, which is the default value.
---
What other targets do, and why we can't do the same:
Other targets support bitcode compilation by the clang driver, but they can do that by using different triples. For example, X86 target supports multiple triples, each of which has its own subclass of `MCAsmInfo`, so it can hardcode the appropriate exception model within those subclasses' constructors. But we don't have separate triples for each exception mode: none, emscripten, and wasm.
---
What this CL does:
If we can figure out whether `-wasm-enable-eh` is passed to the backend, we can programatically set the exception model from the backend, rather than requiring it to be passed.
So we check `WasmEnableEH` and `WasmEnableSjLj` variables, which are `cl::opt` for `-wasm-enable-eh` and `-wasm-enable-sjlj`, in `WebAssemblyMCAsmInfo` constructor, and if either of them is set, we set `MCAsmInfo.ExceptionType` to Wasm. `TargetOptions` cannot be updated there, so we make sure they are the same later.
Fixes https://github.com/emscripten-core/emscripten/issues/15712.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D115893
show more ...
|
| #
95875d24 |
| 24-Nov-2021 |
Zarko Todorovski <[email protected]> |
[LLVM][NFC]Inclusive language: remove occurances of sanity check/test from llvm
Part of work to use more inclusive language in clang/llvm. Rewording some comments and change function and variable na
[LLVM][NFC]Inclusive language: remove occurances of sanity check/test from llvm
Part of work to use more inclusive language in clang/llvm. Rewording some comments and change function and variable names.
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
6d0c7bc1 |
| 07-Oct-2021 |
Paulo Matos <[email protected]> |
[WebAssembly] Implementation of table.get/set for reftypes in LLVM IR
This change implements new DAG nodes TABLE_GET/TABLE_SET, and lowering methods for load and stores of reference types from IR ar
[WebAssembly] Implementation of table.get/set for reftypes in LLVM IR
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
show more ...
|
| #
89b57061 |
| 08-Oct-2021 |
Reid Kleckner <[email protected]> |
Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually us
Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
77b921b8 |
| 07-Aug-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Tidy up EH/SjLj options
This CL is small, but the description can be a little long because I'm trying to sum up the status quo for Emscripten/Wasm EH/SjLj options.
First, this CL adds
[WebAssembly] Tidy up EH/SjLj options
This CL is small, but the description can be a little long because I'm trying to sum up the status quo for Emscripten/Wasm EH/SjLj options.
First, this CL adds an option for Wasm SjLj (`-wasm-enable-sjlj`), which handles SjLj using Wasm EH. The implementation for this will be added as a followup CL, but this adds the option first to do error checking.
This also adds an option for Wasm EH (`-wasm-enable-eh`), which has been already implemented. Before we used `-exception-model=wasm` as the same meaning as enabling Wasm EH, but after we add Wasm SjLj, it will be possible to use Wasm EH instructions for Wasm SjLj while not enabling EH, so going forward, to use Wasm EH, `opt` and `llc` will need this option. This only affects `opt` and `llc` command lines and does not affect Emscripten user interface.
Now we have two modes of EH (Emscripten/Wasm) and also two modes of SjLj (also Emscripten/Wasm). The options corresponding to each of are: - Emscripten EH: `-enable-emscripten-cxx-exceptions` - Emscripten SjLj: `-enable-emscripten-sjlj` - Wasm EH: `-wasm-enable-eh -exception-model=wasm` `-mattr=+exception-handling` - Wasm SjLj: `-wasm-enable-sjlj -exception-model=wasm` `-mattr=+exception-handling` The reason Wasm EH/SjLj's options are a little complicated are `-exception-model` and `-mattr` are common LLVM options ane not under our control. (`-mattr` can be omitted if it is embedded within the bitcode file.)
And we have the following rules of the option composition: - Emscripten EH and Wasm EH cannot be turned on at the same itme - Emscripten SjLj and Wasm SjLj cannot be turned on at the same time - Wasm SjLj should be used with Wasm EH
Which means we now allow these combinations: - Emscripten EH + Emscripten SjLj: the current default in `emcc` - Wasm EH + Emscripten SjLj: This is allowed, but only as an interim step in which we are testing Wasm EH but not yet have a working implementation of Wasm SjLj. This will error out (D107687) in compile time if `setjmp` is called in a function in which Wasm exception is used. - Wasm EH + Wasm SjLj: This will be the default mode later when using Wasm EH. Currently Wasm SjLj implementation doesn't exist, so it doesn't work. - Emscripten EH + Wasm SjLj will not work.
This CL moves these error checking routines to `WebAssemblyPassConfig::addIRPasses`. Not sure if this is an ideal place to do this, but I couldn't find elsewhere. Currently some checking is done within LowerEmscriptenEHSjLj, but these checks only run if LowerEmscriptenEHSjLj runs so it may not run when Wasm EH is used. This moves that to `addIRPasses` and adds some more checks.
Currently LowerEmscriptenEHSjLj pass is responsible for Emscripten EH and Emscripten SjLj. Wasm EH transformations are done in multiple places, including WasmEHPrepare, LateEHPrepare, and CFGStackify. But in the followup CL, LowerEmscriptenEHSjLj pass will be also responsible for a part of Wasm SjLj transformation, because WasmSjLj will also be using several Emscripten library functions, and we will be sharing more than half of the transformation to do that between Emscripten SjLj and Wasm SjLj.
Currently we have `-enable-emscripten-cxx-exceptions` and `-enable-emscripten-sjlj` but these only work for `llc`, because for `llc` we feed these options to the pass but when we run the pass using `opt` the pass will be created with no options and the default options will be used, which turns both Emscripten EH and Emscripten SjLj on.
Now we have one more SjLj option to care for, LowerEmscriptenEHSjLj pass needs a finer way to control these options. This CL removes those default parameters and make LowerEmscriptenEHSjLj pass read directly from command line options specified. So if we only run `opt -wasm-lower-em-ehsjlj`, currently both Emscripten EH and Emscripten SjLj will run, but with this CL, none will run unless we additionally pass `-enable-emscripten-cxx-exceptions` or `-enable-emscripten-sjlj`, or both. This does not affect users; this only affects our `opt` tests because `emcc` will not call either `opt` or `llc`. As a result of this, our existing Emscripten EH/SjLj tests gained one or both of those options in their `RUN` lines.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D107685
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1 |
|
| #
9bd02c43 |
| 02-Aug-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Misc. cosmetic changes in EH (NFC)
- Rename `wasm.catch` intrinsic to `wasm.catch.exn`, because we are planning to add a separate `wasm.catch.longjmp` intrinsic which returns two v
[WebAssembly] Misc. cosmetic changes in EH (NFC)
- Rename `wasm.catch` intrinsic to `wasm.catch.exn`, because we are planning to add a separate `wasm.catch.longjmp` intrinsic which returns two values. - Rename several variables - Remove an unnecessary parameter from `canLongjmp` and `isEmAsmCall` from LowerEmscriptenEHSjLj pass - Add `-verify-machineinstrs` in a test for a safety measure - Add more comments + fix some errors in comments - Replace `std::vector` with `SmallVector` for cases likely with small number of elements - Renamed `EnableEH`/`EnableSjLj` to `EnableEmEH`/`EnableEmSjLj`: We are soon going to add `EnableWasmSjLj`, so this makes the distincion clearer
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D107405
show more ...
|
| #
d3a0a65b |
| 28-Jul-2021 |
Paulo Matos <[email protected]> |
Reland: "[WebAssembly] Add new pass to lower int/ptr conversions of reftypes"
Add new pass LowerRefTypesIntPtrConv to generate debugtrap instruction for an inttoptr and ptrtoint of a reference type
Reland: "[WebAssembly] Add new pass to lower int/ptr conversions of reftypes"
Add new pass LowerRefTypesIntPtrConv to generate debugtrap instruction for an inttoptr and ptrtoint of a reference type instead of erroring, since calling these instructions on non-integral pointers has been since allowed (see ac81cb7e6).
Differential Revision: https://reviews.llvm.org/D107102
show more ...
|
| #
245f2ee6 |
| 02-Aug-2021 |
Paulo Matos <[email protected]> |
Revert "[WebAssembly] Add new pass to lower int/ptr conversions of reftypes"
This reverts commit ce1c59dea6d01e8ec3d4cb911438254283e4646c.
|
| #
ce1c59de |
| 28-Jul-2021 |
Paulo Matos <[email protected]> |
[WebAssembly] Add new pass to lower int/ptr conversions of reftypes
Add new pass LowerRefTypesIntPtrConv to generate trap instruction for an inttoptr and ptrtoint of a reference type instead of erro
[WebAssembly] Add new pass to lower int/ptr conversions of reftypes
Add new pass LowerRefTypesIntPtrConv to generate trap instruction for an inttoptr and ptrtoint of a reference type instead of erroring, since calling these instructions on non-integral pointers has been since allowed (see ac81cb7e6).
Differential Revision: https://reviews.llvm.org/D107102
show more ...
|
|
Revision tags: llvmorg-14-init |
|
| #
46667a10 |
| 22-Jul-2021 |
Paulo Matos <[email protected]> |
[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR
Reland of 31859f896.
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of r
[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR
Reland of 31859f896.
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of reference types from IR globals. Once the lowering creates the new nodes, tablegen pattern matches those and converts them to Wasm global.get/set.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D104797
show more ...
|
| #
ac02baab |
| 09-Jul-2021 |
Derek Schuff <[email protected]> |
WebAssembly: Update datalayout to match fp128 ABI change
This fix goes along with d1a96e906cc03a95cfd41a1f22bdda92651250c7 and makes the fp128 alignment match clang's long double alignment.
Differe
WebAssembly: Update datalayout to match fp128 ABI change
This fix goes along with d1a96e906cc03a95cfd41a1f22bdda92651250c7 and makes the fp128 alignment match clang's long double alignment.
Differential Revision: https://reviews.llvm.org/D105749
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
9647a6f7 |
| 07-Jun-2021 |
Wouter van Oortmerssen <[email protected]> |
[WebAssembly] Added initial type checker to MC Assembler
This to protect against non-sensical instruction sequences being assembled, which would either cause asserts/crashes further down, or a Wasm
[WebAssembly] Added initial type checker to MC Assembler
This to protect against non-sensical instruction sequences being assembled, which would either cause asserts/crashes further down, or a Wasm module being output that doesn't validate.
Unlike a validator, this type checker is able to give type-errors as part of the parsing process, which makes the assembler much friendlier to be used by humans writing manual input.
Because the MC system is single pass (instructions aren't even stored in MC format, they are directly output) the type checker has to be single pass as well, which means that from now on .globaltype and .functype decls must come before their use. An extra pass is added to Codegen to collect information for this purpose, since AsmPrinter is normally single pass / streaming as well, and would otherwise generate this information on the fly.
A `-no-type-check` flag was added to llvm-mc (and any other tools that take asm input) that surpresses type errors, as a quick escape hatch for tests that were not intended to be type correct.
This is a first version of the type checker that ignores control flow, i.e. it checks that types are correct along the linear path, but not the branch path. This will still catch most errors. Branch checking could be added in the future.
Differential Revision: https://reviews.llvm.org/D104945
show more ...
|
| #
c2c0d3ea |
| 02-Jul-2021 |
Roman Lebedev <[email protected]> |
Revert "[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR"
This reverts commit 4facbf213c51e4add2e8c19b08d5e58ad71c72de.
``` ******************** FAIL: LLVM :: CodeGen/WebAssem
Revert "[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR"
This reverts commit 4facbf213c51e4add2e8c19b08d5e58ad71c72de.
``` ******************** FAIL: LLVM :: CodeGen/WebAssembly/funcref-call.ll (44466 of 44468) ******************** TEST 'LLVM :: CodeGen/WebAssembly/funcref-call.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /builddirs/llvm-project/build-Clang12/bin/llc < /repositories/llvm-project/llvm/test/CodeGen/WebAssembly/funcref-call.ll --mtriple=wasm32-unknown-unknown -asm-verbose=false -mattr=+reference-types | /builddirs/llvm-project/build-Clang12/bin/FileCheck /repositories/llvm-project/llvm/test/CodeGen/WebAssembly/funcref-call.ll -- Exit Code: 2
Command Output (stderr): -- llc: /repositories/llvm-project/llvm/include/llvm/Support/LowLevelTypeImpl.h:44: static llvm::LLT llvm::LLT::scalar(unsigned int): Assertion `SizeInBits > 0 && "invalid scalar size"' failed.
```
show more ...
|