[WebAssembly] avoid to enable explicit disabled feature (#80094)

Revert "[WebAssembly] avoid to use explicit disabled feature"

This reverts commit 1a17f2beb9cd1f5bbaa64502ab5c02ff74c199a4.

[WebAssembly] avoid to use explicit disabled feature

In `CoalesceFeaturesAndStripAtomics`, feature string is converted to FeatureBitset and back to feature string. It will lose information about exp

[WebAssembly] avoid to use explicit disabled feature

In `CoalesceFeaturesAndStripAtomics`, feature string is converted to FeatureBitset and back to feature string. It will lose information about explicit diasbled features.

show more ...

[WebAssembly] add: hidden option to disable slow wasm pass (#67715)

Currently for any wasm target, llvm will make a pass that removes
irreducible control flow. (See
[here](https://llvm.org/doxygen

[WebAssembly] add: hidden option to disable slow wasm pass (#67715)

Currently for any wasm target, llvm will make a pass that removes
irreducible control flow. (See
[here](https://llvm.org/doxygen/WebAssemblyFixIrreducibleControlFlow_8cpp.html)).
This can result in O(NumBlocks * NumNestedLoops * NumIrreducibleLoops +
NumLoops * NumLoops) build time, which has resulted in exceedingly long
build times when testing. This PR introduces a hidden flag to skip this
pass, which brings some of our build times down from 30 minutes to ~6
seconds.

show more ...

Ensure NoTrapAfterNoreturn is false for the wasm backend (#65876)

In the WebAssembly back end, the TrapUnreachable option is currently
load-bearing for correctness, inserting wasm `unreachable` ins

Ensure NoTrapAfterNoreturn is false for the wasm backend (#65876)

In the WebAssembly back end, the TrapUnreachable option is currently
load-bearing for correctness, inserting wasm `unreachable` instructions
where needed to create valid wasm. There is another option,
NoTrapAfterNoreturn, that removes some of those traps and causes
incorrect wasm to be emitted.

This turns off `NoTrapAfterNoreturn` for the Wasm backend and adds new
tests.

show more ...

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future chang

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.

This matches other nearby enums.

For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::

show more ...

[llvm] Fix duplicate word typos. NFC

Those fixes were taken from https://reviews.llvm.org/D137338

[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 ...

[clang][WebAssembly] Support wasm32-wasi shared libraries

This adds support for Emscripten-style shared libraries [1] to
non-emscripten targets, such as `wasm32-wasi`. Previously, only static
linki

[clang][WebAssembly] Support wasm32-wasi shared libraries

This adds support for Emscripten-style shared libraries [1] to
non-emscripten targets, such as `wasm32-wasi`. Previously, only static
linking was supported, and the `-shared` and `-fPIC` flags were simply
ignored. Now both flags are honored.

Since WASI runtimes do not necessarily include JavaScript support, we
cannot rely on the JS-based Emscripten linker to link shared libraries.
Instead, we link them using the Component Model proposal [2].

We have prototyped shared library support in `wasi-sdk` [3] and put
together a demo [4] which uses a patched version of `wit-component` [5]
to link libraries using the Component Model. We plan to submit the
required changes upstream to the respective repositories in the next
week or two.

[1] https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md
[2] https://github.com/WebAssembly/component-model/blob/main/design/mvp/examples/SharedEverythingDynamicLinking.md
[3] https://github.com/dicej/wasi-sdk/tree/dynamic-linking
[4] https://github.com/dicej/component-linking-demo
[5] https://github.com/bytecodealliance/wasm-tools/tree/main/crates/wit-component

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D153293

show more ...

[WebAssembly] Initial support for reference type externref in clang

This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __buil

[WebAssembly] Initial support for reference type externref in clang

This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D122215

show more ...

Revert "[clang][WebAssembly] Initial support for reference type externref in clang"

Very likely breaks stage 3 of msan build bot.
Good: 764c88a50ac76a2df2d051a0eb5badc6867aabb6 https://lab.llvm.org/

Revert "[clang][WebAssembly] Initial support for reference type externref in clang"

Very likely breaks stage 3 of msan build bot.
Good: 764c88a50ac76a2df2d051a0eb5badc6867aabb6 https://lab.llvm.org/buildbot/#/builders/74/builds/17058
Looks unrelated: 48b5a06dfcab12cf093a1a3df42cb5b684e2be4c
Bad: 48b5a06dfcab12cf093a1a3df42cb5b684e2be4c https://lab.llvm.org/buildbot/#/builders/74/builds/17059

This reverts commit eb66833d19573df97034a81279eda31b8d19815b.

show more ...

[clang][WebAssembly] Initial support for reference type externref in clang

This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin

[clang][WebAssembly] Initial support for reference type externref in clang

This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.

Differential Revision: https://reviews.llvm.org/D122215

show more ...

Revert "[OpenMP][OMPIRBuilder] Move SIMD alignment calculation to LLVM Frontend"

This reverts commit ed01de67433174d3157e9d239d59dd465d52c6a5.

[OpenMP][OMPIRBuilder] Move SIMD alignment calculation to LLVM Frontend

Currently default simd alignment is specified by Clang specific TargetInfo
class. This class cannot be reused for LLVM Flang.

[OpenMP][OMPIRBuilder] Move SIMD alignment calculation to LLVM Frontend

Currently default simd alignment is specified by Clang specific TargetInfo
class. This class cannot be reused for LLVM Flang. If we move the default
alignment field into TargetMachine class then we can create TargetMachine
objects and query them to find SIMD alignment.

Scope of changes:
1) Added information about maximal allowed SIMD alignment to TargetMachine
classes.
2) Removed getSimdDefaultAlign function from Clang TargetInfo class.
3) Refactored createTargetMachine function.

Reviewed By: jsjodin

Differential Revision: https://reviews.llvm.org/D138496

show more ...

[WebAssembly][LiveDebugValues] Handle target index defs

This adds the missing handling for defs for target index operands, as is
already done for registers.

There are two kinds of target indices: l

[WebAssembly][LiveDebugValues] Handle target index defs

This adds the missing handling for defs for target index operands, as is
already done for registers.

There are two kinds of target indices: local indices and stack operands.

- Locals are something similar to registers in Wasm-land. For local
indices, we can check for local-defining instructions (`local.set` or
`local.tee`).

- Wasm is a stack machine, so we have values in certain Wasm value stack
location, which change when Wasm instructions produce or consume
values. So basically any value-producing instrucion, i.e., instruction
with defs, can change values in the Wasm stack. But I think we don't
need to worry about this here, because `WebAssemblyDebugFixup`, which
runs right before this analysis, makes sure to insert terminating
`DBG_VALUE $noreg` instructions whenever a stack value gets popped.
After `WebAssemblyDebugFixup`, there shouldn't be any `DBG_VALUE`s for
stack operands that don't have a terminating `DBG_VALUE $noreg` within
the same BB.

So this CL only works on `DBG_VALUE`s for locals. When we encounter a
`local.set` or `local.tee` instructions, we delete `DBG_VALUE`s for
those target index locations from the open range set, so they will not
be availble in `OutLocs`. For example,
```
bb.0:
successors: %bb.1
DBG_VALUE target-index(wasm-local) + 2, $noreg, "var", ...
...
local.set 2 ...

bb.1:
; predecessors: %bb.0
; We shouldn't add `DBG_VALUE target (wasm-local) + 2 here because
; it was killed by 'local.set' in bb.0
```

After disabling register coalescing at -O1, the average PC ranges
covered for Emscripten core benchmarks is currently 20.6% in the LLVM
tot. After applying D138943 and this CL, the coverage goes up to 57%.
This also enables LiveDebugValues analysis in the Wasm pipeline by
default.

Reviewed By: dschuff, jmorse

Differential Revision: https://reviews.llvm.org/D140373

show more ...

[llvm][SelectionDAGISel] support -{start|stop}-{before|after}= for remaining targets

Follow up to the series:
1. https://reviews.llvm.org/D140161
2. https://reviews.llvm.org/D140349
3. https://revie

[llvm][SelectionDAGISel] support -{start|stop}-{before|after}= for remaining targets

Follow up to the series:
1. https://reviews.llvm.org/D140161
2. https://reviews.llvm.org/D140349
3. https://reviews.llvm.org/D140331
4. https://reviews.llvm.org/D140323

Completes the work from the previous two for remaining targets.

This creates the following named passes that can be run via
`llc -{start|stop}-{before|after}`:
- arc-isel
- arm-isel
- avr-isel
- bpf-isel
- csky-isel
- hexagon-isel
- lanai-isel
- loongarch-isel
- m68k-isel
- msp430-isel
- mips-isel
- nvptx-isel
- ppc-codegen
- riscv-isel
- sparc-isel
- systemz-isel
- ve-isel
- wasm-isel
- xcore-isel

A nice way to write tests for SelectionDAGISel might be to use a RUN:
line like:
llc -mtriple=<triple> -start-before=<arch>-isel -stop-after=finalize-isel -o -

Fixes: https://github.com/llvm/llvm-project/issues/59538

Reviewed By: asb, zixuan-wu

Differential Revision: https://reviews.llvm.org/D140364

show more ...

CodeGen: Don't lazily construct MachineFunctionInfo

This fixes what I consider to be an API flaw I've tripped over
multiple times. The point this is constructed isn't well defined, so
depending on w

CodeGen: Don't lazily construct MachineFunctionInfo

This fixes what I consider to be an API flaw I've tripped over
multiple times. The point this is constructed isn't well defined, so
depending on where this is first called, you can conclude different
information based on the MachineFunction. For example, the AMDGPU
implementation inspected the MachineFrameInfo on construction for the
stack objects and if the frame has calls. This kind of worked in
SelectionDAG which visited all allocas up front, but broke in
GlobalISel which hasn't visited any of the IR when arguments are
lowered.

I've run into similar problems before with the MIR parser and trying
to make use of other MachineFunction fields, so I think it's best to
just categorically disallow dependency on the MachineFunction state in
the constructor and to always construct this at the same time as the
MachineFunction itself.

A missing feature I still could use is a way to access an custom
analysis pass on the IR here.

show more ...

[WebAssembly] Initialize missing passes in WebAssemblyTargetMachine

These passes were lying around but weren't initialized, so they weren't
showing up in -print-after-all.

Differential Revision: ht

[WebAssembly] Initialize missing passes in WebAssemblyTargetMachine

These passes were lying around but weren't initialized, so they weren't
showing up in -print-after-all.

Differential Revision: https://reviews.llvm.org/D139440

show more ...

Fix @llvm.global_ctors docs (NFC)

Reapply "[CodeGen] Add new pass for late cleanup of redundant definitions."

This reverts commit 122efef8ee9be57055d204d52c38700fe933c033.

- Patch fixed to not reuse definitions from predecessors in

Reapply "[CodeGen] Add new pass for late cleanup of redundant definitions."

This reverts commit 122efef8ee9be57055d204d52c38700fe933c033.

- Patch fixed to not reuse definitions from predecessors in EH landing pads.
- Late review suggestions (by MaskRay) have been addressed.
- M68k/pipeline.ll test updated.
- Init captures added in processBlock() to avoid capturing structured bindings.
- RISCV has this disabled for now.

Original commit message:

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 ...

Revert "Reapply "[CodeGen] Add new pass for late cleanup of redundant definitions.""

This reverts commit 17db0de330f943833296ae72e26fa988bba39cb3.

Some more bots got broken - need to investigate.

Reapply "[CodeGen] Add new pass for late cleanup of redundant definitions."

Init captures added in processBlock() to avoid capturing structured bindings,
which caused the build problems (with clang)

Reapply "[CodeGen] Add new pass for late cleanup of redundant definitions."

Init captures added in processBlock() to avoid capturing structured bindings,
which caused the build problems (with clang).

RISCV has this disabled for now until problems relating to post RA pseudo
expansions are resolved.

show more ...

CodeGen/CommandFlags: Convert Optional to std::optional

Convert Optional<CodeModel> to std::optional<CodeModel>

Revert "[CodeGen] Add new pass for late cleanup of redundant definitions."

Temporarily revert and fix buildbot failure.

This reverts commit 6d12599fd4134c1da63198c74a25490d28c733f6.