Revert "Switch builtin strings to use string tables" (#119638)

Reverts llvm/llvm-project#118734

There are currently some specific versions of MSVC that are miscompiling
this code (we think). We

Revert "Switch builtin strings to use string tables" (#119638)

Reverts llvm/llvm-project#118734

There are currently some specific versions of MSVC that are miscompiling
this code (we think). We don't know why as all the other build bots and
at least some folks' local Windows builds work fine.

This is a candidate revert to help the relevant folks catch their
builders up and have time to debug the issue. However, the expectation
is to roll forward at some point with a workaround if at all possible.

show more ...

[clang] wasm cpu name is supposed to be lime1, not lime (#119262)

Originally added in #112035
cc @sunfishcode

Switch builtin strings to use string tables (#118734)

The Clang binary (and any binary linking Clang as a library), when built
using PIE, ends up with a pretty shocking number of dynamic relocation

Switch builtin strings to use string tables (#118734)

The Clang binary (and any binary linking Clang as a library), when built
using PIE, ends up with a pretty shocking number of dynamic relocations
to apply to the executable image: roughly 400k.

Each of these takes up binary space in the executable, and perhaps most
interestingly takes start-up time to apply the relocations.

The largest pattern I identified were the strings used to describe
target builtins. The addresses of these string literals were stored into
huge arrays, each one requiring a dynamic relocation. The way to avoid
this is to design the target builtins to use a single large table of
strings and offsets within the table for the individual strings. This
switches the builtin management to such a scheme.

This saves over 100k dynamic relocations by my measurement, an over 25%
reduction. Just looking at byte size improvements, using the `bloaty`
tool to compare a newly built `clang` binary to an old one:

```
FILE SIZE VM SIZE
-------------- --------------
+1.4% +653Ki +1.4% +653Ki .rodata
+0.0% +960 +0.0% +960 .text
+0.0% +197 +0.0% +197 .dynstr
+0.0% +184 +0.0% +184 .eh_frame
+0.0% +96 +0.0% +96 .dynsym
+0.0% +40 +0.0% +40 .eh_frame_hdr
+114% +32 [ = ] 0 [Unmapped]
+0.0% +20 +0.0% +20 .gnu.hash
+0.0% +8 +0.0% +8 .gnu.version
+0.9% +7 +0.9% +7 [LOAD #2 [R]]
[ = ] 0 -75.4% -3.00Ki .relro_padding
-16.1% -802Ki -16.1% -802Ki .data.rel.ro
-27.3% -2.52Mi -27.3% -2.52Mi .rela.dyn
-1.6% -2.66Mi -1.6% -2.66Mi TOTAL
```

We get a 16% reduction in the `.data.rel.ro` section, and nearly 30%
reduction in `.rela.dyn` where those reloctaions are stored.

This is also visible in my benchmarking of binary start-up overhead at
least:

```
Benchmark 1: ./old_clang --version
Time (mean ± σ): 17.6 ms ± 1.5 ms [User: 4.1 ms, System: 13.3 ms]
Range (min … max): 14.2 ms … 22.8 ms 162 runs

Benchmark 2: ./new_clang --version
Time (mean ± σ): 15.5 ms ± 1.4 ms [User: 3.6 ms, System: 11.8 ms]
Range (min … max): 12.4 ms … 20.3 ms 216 runs

Summary
'./new_clang --version' ran
1.13 ± 0.14 times faster than './old_clang --version'
```

We get about 2ms faster `--version` runs. While there is a lot of noise
in binary execution time, this delta is pretty consistent, and
represents over 10% improvement. This is particularly interesting to me
because for very short source files, repeatedly starting the `clang`
binary is actually the dominant cost. For example, `configure` scripts
running against the `clang` compiler are slow in large part because of
binary start up time, not the time to process the actual inputs to the
compiler.

----

This PR implements the string tables using `constexpr` code and the
existing macro system. I understand that the builtins are moving towards
a TableGen model, and if complete that would provide more options for
modeling this. Unfortunately, that migration isn't complete, and even
the parts that are migrated still rely on the ability to break out of
the TableGen model and directly expand an X-macro style `BUILTIN(...)`
textually. I looked at trying to complete the move to TableGen, but it
would both require the difficult migration of the remaining targets, and
solving some tricky problems with how to move away from any macro-based
expansion.

I was also able to find a reasonably clean and effective way of doing
this with the existing macros and some `constexpr` code that I think is
clean enough to be a pretty good intermediate state, and maybe give a
good target for the eventual TableGen solution. I was also able to
factor the macros into set of consistent patterns that avoids a
significant regression in overall boilerplate.

show more ...

[WebAssembly] Support the new "Lime1" CPU (#112035)

This adds WebAssembly support for the new [Lime1 CPU].

First, this defines some new target features. These are subsets of
existing
features t

[WebAssembly] Support the new "Lime1" CPU (#112035)

This adds WebAssembly support for the new [Lime1 CPU].

First, this defines some new target features. These are subsets of
existing
features that reflect implementation concerns:

- "call-indirect-overlong" - implied by "reference-types"; just the
overlong
encoding for the `call_indirect` immediate, and not the actual reference
types.

- "bulk-memory-opt" - implied by "bulk-memory": just `memory.copy` and
`memory.fill`, and not the other instructions in the bulk-memory
proposal.

Next, this defines a new target CPU, "lime1", which enables
mutable-globals,
bulk-memory-opt, multivalue, sign-ext, nontrapping-fptoint,
extended-const,
and call-indirect-overlong. Unlike the default "generic" CPU, "lime1" is
meant
to be frozen, and followed up by "lime2" and so on when new features are
desired.

[Lime1 CPU]:
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md#lime1

---------

Co-authored-by: Heejin Ahn <aheejin@gmail.com>

show more ...

[WebAssembly] Define call-indirect-overlong and bulk-memory-opt features (#117087)

This defines some new target features. These are subsets of existing
features that reflect implementation concerns

[WebAssembly] Define call-indirect-overlong and bulk-memory-opt features (#117087)

This defines some new target features. These are subsets of existing
features that reflect implementation concerns:

- "call-indirect-overlong" - implied by "reference-types"; just the
overlong encoding for the `call_indirect` immediate, and not the actual
reference types.

- "bulk-memory-opt" - implied by "bulk-memory": just `memory.copy` and
`memory.fill`, and not the other instructions in the bulk-memory
proposal.

This is split out from https://github.com/llvm/llvm-project/pull/112035.

---------

Co-authored-by: Heejin Ahn <aheejin@gmail.com>

show more ...

[WebAssembly] Enable nontrapping-fptoint and bulk-memory by default. (#112049)

We were prepared to enable these features [back in February], but they
got pulled for what appear to be unrelated reas

[WebAssembly] Enable nontrapping-fptoint and bulk-memory by default. (#112049)

We were prepared to enable these features [back in February], but they
got pulled for what appear to be unrelated reasons. So let's have
another try at enabling them!

Another motivation here is that it'd be convenient for the [Lime1
proposal] if "lime1" is close to a subset of "generic" (missing only
for extended-const).

[back in February]:
https://github.com/WebAssembly/tool-conventions/issues/158#issuecomment-1931119512
[Lime1 proposal]: https://github.com/llvm/llvm-project/pull/112035

show more ...

[WebAssembly] Implement the wide-arithmetic proposal (#111598)

This commit implements the [wide-arithmetic] proposal which has recently
reached phase 2 in the WebAssembly proposals process. The goa

[WebAssembly] Implement the wide-arithmetic proposal (#111598)

This commit implements the [wide-arithmetic] proposal which has recently
reached phase 2 in the WebAssembly proposals process. The goal here is
to implement support in LLVM for emitting these instructions which are
gated behind a new feature flag by default. A new `wide-arithmetic`
feature flag is introduced which gates these four new instructions from
being emitted.

Emission of each instruction itself is relatively simple given LLVM's
preexisting lowering rules and infrastructure. The main gotcha is that
due to the multi-result nature of all of these instructions it needed
the lowerings to be implemented in C++ rather than in TableGen.

[wide-arithmetic]: https://github.com/WebAssembly/wide-arithmetic

show more ...

[WebAssembly] Change half-precision feature name to fp16. (#105434)

This better aligns with how the feature is being referred to and what
runtimes (V8) are calling it.

[WebAssembly] Re-enable reference types by default (#93261)

Now that we are about to upgrade emsdk's default node to v18.20.3
(https://github.com/emscripten-core/emsdk/pull/1387), we can re-enable

[WebAssembly] Re-enable reference types by default (#93261)

Now that we are about to upgrade emsdk's default node to v18.20.3
(https://github.com/emscripten-core/emsdk/pull/1387), we can re-enable
reference-types by default again. This effectively reverts #90792.

show more ...

[WebAssembly] Add all remaining features to bleeding-edge (#90875)

I'm not entirely sure what the criteria for 'bleeding-edge' used to be,
but at this point it seems to be the set of all added feat

[WebAssembly] Add all remaining features to bleeding-edge (#90875)

I'm not entirely sure what the criteria for 'bleeding-edge' used to be,
but at this point it seems to be the set of all added features in LLVM.
This adds remaining features to bleeding-edge config.

show more ...

[WebAssembly] Sort target features (NFC) (#90777)

[WebAssembly] Disable reference types in generic CPU (#90792)

#80923 newly enabled multivalue and reference-types in the generic CPU.
But enabling reference-types ended up breaking up Wasm's Chromi

[WebAssembly] Disable reference types in generic CPU (#90792)

#80923 newly enabled multivalue and reference-types in the generic CPU.
But enabling reference-types ended up breaking up Wasm's Chromium CI
(https://chromium-review.googlesource.com/c/emscripten-releases/+/5500231)
because the way the table index is encoded is different from MVP (u32)
vs. reference-types (LEB), which caused different encodings for
`call_indirect`.

And Chromium CI's and Emscripten's minimum required node version is v16,
which does not yet support reference-types, which does not recognize
that table index encoding. reference-types is first supported in node
v17.2.

We knew the current minimum required node for Emscripten (v16) did not
support reference-types, but thought it was fine because unless you
explicitly use `__funcref` or `__externref` things would be fine, and if
you want to use them explicitly, you would have a newer node. But it
turned out it also affected the encoding of `call_indirect`.

While we are discussing the potential solutions, I will disable
reference-types to unblock the rolls.

show more ...

[WebAssembly] Add preprocessor define for half-precision (#90528)

This adds the preprocessor define for the half-precision feature and
also adds preprocessor tests.

[WebAssembly] Enable multivalue and reference-types in generic CPU config (#80923)

This enables multivalue and reference-types in `-mcpu=generic`
configuration. These proposals have been

[WebAssembly] Enable multivalue and reference-types in generic CPU config (#80923)

This enables multivalue and reference-types in `-mcpu=generic`
configuration. These proposals have been standardized and supported in
all major browsers for several years at this point:
https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md

show more ...

[WebAssembly] Add half-precision feature (#90248)

This currently only defines a constant, but in the future will be used
to gate builtins for experimenting and prototyping half-precision
proposal

[WebAssembly] Add half-precision feature (#90248)

This currently only defines a constant, but in the future will be used
to gate builtins for experimenting and prototyping half-precision
proposal (https://github.com/WebAssembly/half-precision).

show more ...

[WebAssembly] Tidy up wasm-target-features.c (#89778)

This tidies up `wasm-target-features.c` cosmetically:
- Sorts the feature tests alphabetically
- Adds a space after colons

[WebAssembly] Add multiple memories feature

Adding to allow users to get this flag into the target features section for
future use cases.

Reviewed By: tlively, aheejin

Differential Revision: https

[WebAssembly] Add multiple memories feature

Adding to allow users to get this flag into the target features section for
future use cases.

Reviewed By: tlively, aheejin

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

show more ...

[clang][WebAssembly] Implement support for table types and builtins

This commit implements support for WebAssembly table types and
respective builtins. Table tables are WebAssembly objects to store

[clang][WebAssembly] Implement support for table types and builtins

This commit implements support for WebAssembly table types and
respective builtins. Table tables are WebAssembly objects to store
reference types. They have a large amount of semantic restrictions
including, but not limited to, only being allowed to be declared
at the top-level as static arrays of zero-length. Not being arguments
or result of functions, not being stored ot memory, etc.

This commit introduces the __attribute__((wasm_table)) to attach to
arrays of WebAssembly reference types. And the following builtins to
manage tables:

* ref __builtin_wasm_table_get(table, idx)
* void __builtin_wasm_table_set(table, idx, ref)
* uint __builtin_wasm_table_size(table)
* uint __builtin_wasm_table_grow(table, ref, uint)
* void __builtin_wasm_table_fill(table, idx, ref, uint)
* void __builtin_wasm_table_copy(table, table, uint, uint, uint)

This commit also enables reference-types feature at bleeding-edge.

This is joint work with Alex Bradbury (@asb).

Reviewed By: aaron.ballman

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

show more ...

[clang] Optimize clang::Builtin::Info density

Reorganize clang::Builtin::Info to have them naturally align on 4 bytes
boundaries.

Instead of storing builtin headers as a straight char pointer, enum

[clang] Optimize clang::Builtin::Info density

Reorganize clang::Builtin::Info to have them naturally align on 4 bytes
boundaries.

Instead of storing builtin headers as a straight char pointer, enumerate
them and store the enum. It allows to use a small enum instead of a
pointer to reference them.

On a 64 bit machine, this brings sizeof(clang::Builtin::Info) from 56
down to 48 bytes.

On a release build on my Linux 64 bit machine, it shrinks the size of
libclang-cpp.so by 193kB.

The impact on performance is negligible in terms of instruction count,
but the wall time seems better, see
https://llvm-compile-time-tracker.com/compare.php?from=b3d8639f3536a4876b511aca9fb7948ff9266cee&to=a89b56423f98b550260a58c41e64aff9e56b76be&stat=task-clock

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential

Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[Hexagon][VE][WebAssembly] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

Reviewed By: kparzysz, aheejin, MaskRay

Differential Revision: https://revi

[Hexagon][VE][WebAssembly] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

Reviewed By: kparzysz, aheejin, MaskRay

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

show more ...

[clang] Use a StringRef instead of a raw char pointer to store builtin and call information

This avoids recomputing string length that is already known at compile time.

It has a slight impact on pr

[clang] Use a StringRef instead of a raw char pointer to store builtin and call information

This avoids recomputing string length that is already known at compile time.

It has a slight impact on preprocessing / compile time, see

https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u

This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.

The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.

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

show more ...

[WebAssembly] Update supported features in the generic CPU configuration

Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features
enabled by default.

These features are all [

[WebAssembly] Update supported features in the generic CPU configuration

Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features
enabled by default.

These features are all [finished proposals], and all major wasm engines
support them.

[finished proposals]: https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md

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

show more ...

[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

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

[WebAssembly] Add new target feature in support of 'extended-const' proposal

We don't yet do anything when this feature is enabled, this change
just lays the ground work by accepting that there is s

[WebAssembly] Add new target feature in support of 'extended-const' proposal

We don't yet do anything when this feature is enabled, this change
just lays the ground work by accepting that there is such a feature.

See https://github.com/WebAssembly/extended-const

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

show more ...