#
6d12599f |
| 06-Apr-2022 |
Jonas Paulsson <paulsson@linux.vnet.ibm.com> |
[CodeGen] Add new pass for late cleanup of redundant definitions.
A new pass MachineLateInstrsCleanup is added to be run after PEI.
This is a simple pass that removes redundant and identical instru
[CodeGen] Add new pass for late cleanup of redundant definitions.
A new pass MachineLateInstrsCleanup is added to be run after PEI.
This is a simple pass that removes redundant and identical instructions whenever found by scanning the MF once while keeping track of register definitions in a map. These instructions are typically immediate loads resulting from rematerialization, and address loads emitted by target in eliminateFrameInde().
This is enabled by default, but a target could easily disable it by means of 'disablePass(&MachineLateInstrsCleanupID);'.
This late cleanup is naturally not "optimal" in removing instructions as it is done by looking at phys-regs, but still quite effective. It would be desirable to improve other parts of CodeGen and avoid these redundant instructions in the first place, but there are no ideas for this yet.
Differential Revision: https://reviews.llvm.org/D123394
Reviewed By: RKSimon, foad, craig.topper, arsenm, asb
show more ...
|
#
d9ae0788 |
| 16-Nov-2022 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Disable register coalescing at -O1
This disables `RegisterCoalescer` pass at -O1, which currently runs for all levels except for -O0, as a part of common optimization pipeline.
`Regis
[WebAssembly] Disable register coalescing at -O1
This disables `RegisterCoalescer` pass at -O1, which currently runs for all levels except for -O0, as a part of common optimization pipeline.
`RegisterCoalescer` pass degrades Wasm debug info quality by a significant margin. When I use `LiveDebugValue` analysis, disabling this increases the average PC ranges covered by 15% on Emscripten core benchmarks (52% -> 66.8%). (Our code is currently not using `LiveDebugValues` analysis at the moment, and the experiment was done on a local setting that enabled it. I'm planning to upstream it soon.)
In Emscripten core benchmarks, disabling this at -O1 causes +4.5% in code size and +1% in the number of locals. The number of globals stays the same. I believe this tradeoff is acceptable given that -O1 is not usually used in production builds and is often used for debugging when the application size is very large.
The plan is to investigate and fix what's causing the degradation in that pass, but for now disabling it seems like a low-hanging quick fix.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D138455
show more ...
|
#
ff2b60bb |
| 02-Nov-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
WebAssembly: Remove MachineFunction reference from MFI
The MachineFunctionInfo here is a bit awkward because WasmEHInfo is in the MachineFunction but handled from the target code. Either everything
WebAssembly: Remove MachineFunction reference from MFI
The MachineFunctionInfo here is a bit awkward because WasmEHInfo is in the MachineFunction but handled from the target code. Either everything should move into WebAssembly or into the MachineFunction for MIR serialization.
show more ...
|
#
e0e687a6 |
| 20-Jun-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Don't use Optional::hasValue (NFC)
|
#
59726668 |
| 20-May-2022 |
Dan Gohman <dev@sunfishcode.online> |
[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 <aheejin@gmail.com> |
[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 ...
|
#
39f15686 |
| 05-Apr-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
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 <craig.topper@sifive.com> |
[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 <julian.lettner@apple.com> |
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 <zequanwu@google.com> |
Revert "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"
This reverts commit 22570bac694396514fff18dec926558951643fa6.
|
#
22570bac |
| 09-Mar-2022 |
Julian Lettner <julian.lettner@apple.com> |
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 <llvm-dev@redking.me.uk> |
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 <julian.lettner@apple.com> |
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 ...
|
#
c4b1a63a |
| 25-Feb-2022 |
Jameson Nash <vtjnash@gmail.com> |
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 <aheejin@gmail.com> |
[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 ...
|
#
4625b848 |
| 16-Dec-2021 |
Heejin Ahn <aheejin@gmail.com> |
[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 <zarko@ca.ibm.com> |
[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 ...
|
#
6d0c7bc1 |
| 07-Oct-2021 |
Paulo Matos <pmatos@igalia.com> |
[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 <rnk@google.com> |
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 ...
|
#
77b921b8 |
| 07-Aug-2021 |
Heejin Ahn <aheejin@gmail.com> |
[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 ...
|
#
9bd02c43 |
| 02-Aug-2021 |
Heejin Ahn <aheejin@gmail.com> |
[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 <pmatos@igalia.com> |
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 <pmatos@igalia.com> |
Revert "[WebAssembly] Add new pass to lower int/ptr conversions of reftypes"
This reverts commit ce1c59dea6d01e8ec3d4cb911438254283e4646c.
|
#
ce1c59de |
| 28-Jul-2021 |
Paulo Matos <pmatos@igalia.com> |
[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 ...
|
#
46667a10 |
| 22-Jul-2021 |
Paulo Matos <pmatos@igalia.com> |
[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 ...
|