#
09989996 |
| 12-Jul-2024 |
paperchalice <liujunchang97@outlook.com> |
[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)
- Add `MachineBlockFrequencyAnalysis`.
- Add `MachineBlockFrequencyPrinterPass`.
- Use `MachineBlockFrequencyInfoWrapperPass
[CodeGen][NewPM] Port `machine-block-freq` to new pass manager (#98317)
- Add `MachineBlockFrequencyAnalysis`.
- Add `MachineBlockFrequencyPrinterPass`.
- Use `MachineBlockFrequencyInfoWrapperPass` in legacy pass manager.
- `LazyMachineBlockFrequencyInfo::print` is empty, drop it due to new
pass manager migration.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
c179d50f |
| 28-May-2024 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add exnref type (#93586)
This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:
https://github.com/WebAssembly/exception-handling/blob/mai
[WebAssembly] Add exnref type (#93586)
This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:
https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md:x
show more ...
|
Revision tags: 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 |
|
#
984dc4b9 |
| 26-Jul-2023 |
Reid Kleckner <rnk@google.com> |
[WebAssembly] Create separation between MC and CodeGen layers
Move WebAssemblyUtilities from Utils to the CodeGen library. It primarily deals in MIR layer types, so it really lives in the CodeGen li
[WebAssembly] Create separation between MC and CodeGen layers
Move WebAssemblyUtilities from Utils to the CodeGen library. It primarily deals in MIR layer types, so it really lives in the CodeGen library.
Move a variety of other things around to try create better separation.
See issue #64166 for more info on layering.
Move llvm/include/CodeGen/WasmAddressSpaces.h back to llvm/lib/Target/WebAssembly/Utils.
Differential Revision: https://reviews.llvm.org/D156472
show more ...
|
Revision tags: 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 |
|
#
6d33affa |
| 14-Mar-2023 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add comments on local.tee transformation
We have a good comment on `TEE` transformation in `RegStackify`: https://github.com/llvm/llvm-project/blob/547e3456660000a16fc5c2a2f819f1a2b5d3
[WebAssembly] Add comments on local.tee transformation
We have a good comment on `TEE` transformation in `RegStackify`: https://github.com/llvm/llvm-project/blob/547e3456660000a16fc5c2a2f819f1a2b5d35b5d/llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp#L613-L632
And I think it can be helpful to have some more comments on how the `TEE`s created in `RegStackify` are converted into `LOCAL_TEE`s.
Variable `OldReg` is changed to `DefReg` to be consistent with `RegStackify`'s comment.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D146084
show more ...
|
Revision tags: llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2 |
|
#
a07584d5 |
| 03-Feb-2023 |
Jay Foad <jay.foad@amd.com> |
[CodeGen] Make more use of MachineOperand::getOperandNo. NFC.
Differential Revision: https://reviews.llvm.org/D143252
|
Revision tags: 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, working, 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, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
#
d6b07348 |
| 19-Jan-2022 |
Jim Lin <jim@andestech.com> |
[NFC] Use Register instead of unsigned
|
Revision tags: llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
a320f877 |
| 25-Oct-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Fix debug locations for ExplicitLocals pass
This is a reworked version of the reverted patch: https://reviews.llvm.org/D112487 Note that a) it doesn't need the test changes anymore, an
[WebAssembly] Fix debug locations for ExplicitLocals pass
This is a reworked version of the reverted patch: https://reviews.llvm.org/D112487 Note that a) it doesn't need the test changes anymore, and b) I checked at least locally it passes other.test_pthread_lsan_leak
Differential Revision: https://reviews.llvm.org/D113208
show more ...
|
#
3b039c68 |
| 29-Oct-2021 |
Sam Clegg <sbc@chromium.org> |
Revert "[WebAssembly] Fix debug locations for ExplicitLocals pass"
This reverts commit a66451ebbe450a5e9dc6baf0c4e9f5738df589a2.
This caused a failure when integrated with emscripten: https://ci.ch
Revert "[WebAssembly] Fix debug locations for ExplicitLocals pass"
This reverts commit a66451ebbe450a5e9dc6baf0c4e9f5738df589a2.
This caused a failure when integrated with emscripten: https://ci.chromium.org/ui/p/emscripten-releases/builders/try/linux/b8832019855439718609/overview
show more ...
|
#
a66451eb |
| 25-Oct-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Fix debug locations for ExplicitLocals pass
Differential Revision: https://reviews.llvm.org/D112487
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
#
85b4b21c |
| 21-Sep-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use make_early_inc_range (NFC)
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
82f92e35 |
| 21-Apr-2021 |
Andy Wingo <wingo@igalia.com> |
[WebAssembly][CodeGen] IR support for WebAssembly local variables
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a point
[WebAssembly][CodeGen] IR support for WebAssembly local variables
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
show more ...
|
#
bc1ad6e3 |
| 31-May-2021 |
Andy Wingo <wingo@igalia.com> |
Revert "[WebAssembly][CodeGen] IR support for WebAssembly local variables"
This reverts commit bf35f4af51cddd743435bb6b94a45592c967891a. There was an error in a shared-library build.
|
#
bf35f4af |
| 21-Apr-2021 |
Andy Wingo <wingo@igalia.com> |
[WebAssembly][CodeGen] IR support for WebAssembly local variables
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a point
[WebAssembly][CodeGen] IR support for WebAssembly local variables
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
show more ...
|
#
ca5f07f8 |
| 28-May-2021 |
Andy Wingo <wingo@igalia.com> |
Revert "[WebAssembly][CodeGen] IR support for WebAssembly local variables"
This reverts commit 00ecf18979e3326b3afee8af3dc701c53ffdc93f, as it broke the AMDGPU build. Will reland later with a fix.
|
#
00ecf189 |
| 21-Apr-2021 |
Andy Wingo <wingo@igalia.com> |
[WebAssembly][CodeGen] IR support for WebAssembly local variables
This patch adds TargetStackID::WasmLocal. This stack holds locations of values that are only addressable by name -- not via a point
[WebAssembly][CodeGen] IR support for WebAssembly local variables
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
show more ...
|
#
a64ebb86 |
| 23-May-2021 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the const
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the constructor of `WebAssemblyDebugValueManager` in D102589, but it made the class error-prone to use because it deletes instructions within the constructor and thus invalidates existing iterators within the BB, so the user of the class should take special care not to use invalidated iterators. This actually caused a bug in ExplicitLocals pass.
Instead of trying to fix ExplicitLocals pass to make the iterator usage correct, which is possible but error-prone, this adds NullifyDebugValueLists pass that nullifies all `DBG_VALUE_LIST` instructions before we run WebAssembly specific passes in the backend. We can remove this pass after we implement handlers for `DBG_VALUE_LIST`s in `WebAssemblyDebugValueManager` and elsewhere.
Fixes https://github.com/emscripten-core/emscripten/issues/14255.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D102999
show more ...
|
#
6e1c1dac |
| 16-May-2021 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Nullify DBG_VALUE_LISTs in DebugValueManager
WebAssemblyDebugValueManager class currently does not handle DBG_VALUE_LIST instructions correctly for two reasons, which are explained in
[WebAssembly] Nullify DBG_VALUE_LISTs in DebugValueManager
WebAssemblyDebugValueManager class currently does not handle DBG_VALUE_LIST instructions correctly for two reasons, which are explained in https://bugs.llvm.org/show_bug.cgi?id=50361.
This effectively nullifies DBG_VALUE_LISTs in WebAssemblyDebugValueManager so that the info will appear as "optimized out" in debuggers but still be at least correct in the meantime.
Reviewed By: dschuff, jmorse
Differential Revision: https://reviews.llvm.org/D102589
show more ...
|
#
0b2bc69b |
| 21-Apr-2021 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Put utility functions in Utils directory (NFC)
This CL 1. Creates Utils/ directory under lib/Target/WebAssembly 2. Moves existing WebAssemblyUtilities.cpp|h into the Utils/ directory 3
[WebAssembly] Put utility functions in Utils directory (NFC)
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
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
#
52e240a0 |
| 26-Dec-2020 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Remove exnref and br_on_exn
This removes `exnref` type and `br_on_exn` instruction. This is effectively NFC because most uses of these were already removed in the previous CLs.
Review
[WebAssembly] Remove exnref and br_on_exn
This removes `exnref` type and `br_on_exn` instruction. This is effectively NFC because most uses of these were already removed in the previous CLs.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D94041
show more ...
|
#
5c38ae36 |
| 06-Jan-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Fixed byval args missing DWARF DW_AT_LOCATION
A struct in C passed by value did not get debug information. Such values are currently lowered to a Wasm local even in -O0 (not to an allo
[WebAssembly] Fixed byval args missing DWARF DW_AT_LOCATION
A struct in C passed by value did not get debug information. Such values are currently lowered to a Wasm local even in -O0 (not to an alloca like on other archs), which becomes a Target Index operand (TI_LOCAL). The DWARF writing code was not emitting locations in for TI's specifically if the location is a single range (not a list).
In addition, the ExplicitLocals pass which removes the ARGUMENT pseudo instructions did not update the associated DBG_VALUEs, and couldn't even find these values since the code assumed such instructions are adjacent, which is not the case here.
Also fixed asm printing of TIs needed by a test.
Differential Revision: https://reviews.llvm.org/D94140
show more ...
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
#
60653e24 |
| 30-Nov-2020 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Support select and block for reference types
This adds missing `select` instruction support and block return type support for reference types. Also refactors WebAssemblyInstrRef.td and
[WebAssembly] Support select and block for reference types
This adds missing `select` instruction support and block return type support for reference types. Also refactors WebAssemblyInstrRef.td and rearranges tests in reference-types.s. Tests don't include `exnref` types, because we currently don't support `exnref` for `ref.null` and the type will be removed soon anyway.
Reviewed By: tlively, sbc100, wingo
Differential Revision: https://reviews.llvm.org/D92359
show more ...
|
Revision tags: llvmorg-11.0.1-rc1 |
|
#
69e2797e |
| 23-Oct-2020 |
Paulo Matos <pmatos@igalia.com> |
[WebAssembly] Implementation of (most) table instructions
Implementation of instructions table.get, table.set, table.grow, table.size, table.fill, table.copy.
Missing instructions are table.init an
[WebAssembly] Implementation of (most) table instructions
Implementation of instructions table.get, table.set, table.grow, table.size, table.fill, table.copy.
Missing instructions are table.init and elem.drop as they deal with element sections which are not yet implemented.
Added more tests to tables.s
Differential Revision: https://reviews.llvm.org/D89797
show more ...
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
#
c5d24009 |
| 18-Jun-2020 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
WebAssembly: Don't store MachineFunction in MachineFunctionInfo
Soon it will be disallowed to depend on MachineFunction state in the constructor. This was only being used to get the MachineRegisterI
WebAssembly: Don't store MachineFunction in MachineFunctionInfo
Soon it will be disallowed to depend on MachineFunction state in the constructor. This was only being used to get the MachineRegisterInfo for an assert, which I'm not sure is necessarily worth it. I would think any missing defs would be caught by the verifier later instead.
show more ...
|
Revision tags: llvmorg-10.0.1-rc1 |
|
#
2b7fe086 |
| 30-Apr-2020 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Added Debug Fixup pass
This pass changes debug_value instructions referring to stackified registers into TI_OPERAND_STACK with correct stack depth.
|
#
e110897e |
| 25-Mar-2020 |
Derek Schuff <dschuff@chromium.org> |
[WEbAssembly] Clear frame base vreg in explicit-locals when stack pointer is dead
Having an alloca in a function causes the stack pointer to be generated in the prolog, but if it's unused other than
[WEbAssembly] Clear frame base vreg in explicit-locals when stack pointer is dead
Having an alloca in a function causes the stack pointer to be generated in the prolog, but if it's unused other than for debug info, explicit-locals will drop it and not allocate a local. In this case we need to reset the FrameBaseVreg.
Differential Revision: https://reviews.llvm.org/D76784
show more ...
|