History log of /llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp (Results 1 – 25 of 63)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


123