Skip to content

[Strings] Add a string-builtins feature, and lift/lower automatically when enabled #7601

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 26 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -194,6 +194,17 @@ There are a few differences between Binaryen IR and the WebAssembly language:
rare cases (we avoid this overhead in the common case where the `br_if`
value is unused).

* Strings

* When the string builtins feature is enabled (`--enable-string-builtins`),
string operations are optimized. First, string imports are lifted into
stringref operations, before any default optimization passes. Those
stringref operations can then be optimized (e.g., a concat of constants
turns into a concatenated constant). When we are about to finish running
default optimizations, we lower stringref back into string builtins. (Note:
reference types and GC must also be enabled, as imported string operations
depend on GC arrays.)

As a result, you might notice that round-trip conversions (wasm => Binaryen IR
=> wasm) change code a little in some corner cases.

Expand Down
12 changes: 10 additions & 2 deletions scripts/fuzz_opt.py
Original file line number Diff line number Diff line change
Expand Up @@ -51,8 +51,16 @@
# parameters

# feature options that are always passed to the tools.
# XXX fp16 is not yet stable, remove from here when it is
CONSTANT_FEATURE_OPTS = ['--all-features', '--disable-fp16']
CONSTANT_FEATURE_OPTS = [
'--all-features',
# TODO fp16 is not yet stable, remove from here when it is
'--disable-fp16',
# TODO if we enable string-builtins then if the input module has strings,
# the output after lowering will have string imports, and the
# interpreter does not yet support executing those (we'd need to handle
# all the imported functions, magic constants, and the section)
'--disable-string-builtins',
]

INPUT_SIZE_MIN = 1024
INPUT_SIZE_MEAN = 40 * 1024
Expand Down
5 changes: 4 additions & 1 deletion scripts/test/fuzzing.py
Original file line number Diff line number Diff line change
Expand Up @@ -19,10 +19,13 @@
unfuzzable = [
# Float16 is still experimental.
'f16.wast',
# TODO: fuzzer and interpreter support for strings
# TODO: fuzzer and interpreter support for strings, including limitations
# like the fuzzer not handling (ref extern) imports (there is no way
# to create a replacement value)
'strings.wast',
'simplify-locals-strings.wast',
'string-lowering-instructions.wast',
'string-builtins.wast',
# TODO: fuzzer and interpreter support for extern conversions
'extern-conversions.wast',
# ignore DWARF because it is incompatible with multivalue atm
Expand Down
25 changes: 19 additions & 6 deletions src/pass.h
Original file line number Diff line number Diff line change
Expand Up @@ -324,26 +324,39 @@ struct PassRunner {
// warning.
void addIfNoDWARFIssues(std::string passName);

// Adds the default set of optimization passes; this is
// what -O does.
void addDefaultOptimizationPasses();
// By default, we do not know if we are running first in the ordering of
// optimization passes, or last - we could be anywhere.
struct Ordering {
bool first;
bool last;
};
static constexpr Ordering UnknownOrdering = {false, false};

// Adds the default set of optimization passes; this is what -O does.
//
// The ordering indicates our position relative to other default
// optimizations, that is, if ordering.first then we are first.
void addDefaultOptimizationPasses(Ordering ordering = UnknownOrdering);

// Adds the default optimization passes that work on
// individual functions.
void addDefaultFunctionOptimizationPasses();
void
addDefaultFunctionOptimizationPasses(Ordering ordering = UnknownOrdering);

// Adds the default optimization passes that work on
// entire modules as a whole, and make sense to
// run before function passes.
void addDefaultGlobalOptimizationPrePasses();
void
addDefaultGlobalOptimizationPrePasses(Ordering ordering = UnknownOrdering);

// Adds the default optimization passes that work on
// entire modules as a whole, and make sense to
// run after function passes.
// This is run at the very end of the optimization
// process - you can assume no other opts will be run
// afterwards.
void addDefaultGlobalOptimizationPostPasses();
void
addDefaultGlobalOptimizationPostPasses(Ordering ordering = UnknownOrdering);

// Run the passes on the module
void run();
Expand Down
38 changes: 31 additions & 7 deletions src/passes/pass.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -605,13 +605,13 @@ void PassRunner::addIfNoDWARFIssues(std::string passName) {
}
}

void PassRunner::addDefaultOptimizationPasses() {
addDefaultGlobalOptimizationPrePasses();
addDefaultFunctionOptimizationPasses();
addDefaultGlobalOptimizationPostPasses();
void PassRunner::addDefaultOptimizationPasses(Ordering ordering) {
addDefaultGlobalOptimizationPrePasses(ordering);
addDefaultFunctionOptimizationPasses(ordering);
addDefaultGlobalOptimizationPostPasses(ordering);
}

void PassRunner::addDefaultFunctionOptimizationPasses() {
void PassRunner::addDefaultFunctionOptimizationPasses(Ordering ordering) {
// All the additions here are optional if DWARF must be preserved. That is,
// when DWARF is relevant we run fewer optimizations.
// FIXME: support DWARF in all of them.
Expand Down Expand Up @@ -723,7 +723,17 @@ void PassRunner::addDefaultFunctionOptimizationPasses() {
addIfNoDWARFIssues("vacuum"); // just to be safe
}

void PassRunner::addDefaultGlobalOptimizationPrePasses() {
void PassRunner::addDefaultGlobalOptimizationPrePasses(Ordering ordering) {
// If we are optimizing string builtins then we lift at the very start of the
// optimization pipeline, not just at the beginning here, but only when we are
// ordered before other bundles of passes.
//
// We check for GC for symmetry with the lowering pass, see comment in
// addDefaultGlobalOptimizationPostPasses() below.
if (wasm->features.hasStringBuiltins() && wasm->features.hasGC() &&
options.optimizeLevel >= 2 && ordering.first) {
addIfNoDWARFIssues("string-lifting");
}
// Removing duplicate functions is fast and saves work later.
addIfNoDWARFIssues("duplicate-function-elimination");
// Do a global cleanup before anything heavy, as it is fairly fast and can
Expand Down Expand Up @@ -772,7 +782,7 @@ void PassRunner::add(std::string passName, std::optional<std::string> passArg) {
doAdd(std::move(pass));
}

void PassRunner::addDefaultGlobalOptimizationPostPasses() {
void PassRunner::addDefaultGlobalOptimizationPostPasses(Ordering ordering) {
if (options.optimizeLevel >= 2 || options.shrinkLevel >= 1) {
addIfNoDWARFIssues("dae-optimizing");
}
Expand All @@ -794,6 +804,20 @@ void PassRunner::addDefaultGlobalOptimizationPostPasses() {
} else {
addIfNoDWARFIssues("simplify-globals");
}

// Lower away strings at the very very end. We do this before
// remove-unused-module-elements so we don't add unused imports, and also
// before reorder-globals, which will sort the new globals.
//
// Note we also test for GC here, as the pass adds imports that use GC arrays
// (and externref). Those imports may be unused, but they exist until
// remove-unused-module-elements cleans them up, which would cause an error in
// between.
if (wasm->features.hasStringBuiltins() && wasm->features.hasGC() &&
options.optimizeLevel >= 2 && ordering.last) {
addIfNoDWARFIssues("string-lowering-magic-imports");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use string-lowering-magic-imports-assert to make sure we aren't accidentally doing any optimizations that would result in us emitting a non-standard custom section for non-UTF-8 string constants?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, isn't the section standardized?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. The standard solution is the magic imports, which can only handle valid UTF-8 strings. The custom section is a random thing we experimented with on the way to developing magic imports.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the spec solution for non-UTF8 strings, then?

Separately, if we assert here, then any module with a non-utf8 stringref will assert if you just do -all -O2... that seems wrong to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no spec solution for non-UTF-8 strings. We could synthesize them in a start function if we had to, but I don't think that should be necessary. No input module should have non-UTF-8 strings because they are not expressible with string builtins, and our optimizations should not produce new invalid non-UTF-8 strings, so no output module should have non-UTF-8 strings. Input modules that use stringref to represent non-UTF-8 strings probably don't want this lowering to occur in the first place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do the lifting/lowering only when stringref is not enabled

Hmm, seems weird for -all to do less than -all --disable-stringref. More features should mean more things to optimize, normally.

Ok, we can do the lifting when either stringref or string-builtins are enabled, then lower only if string-builtins and not stringref are enabled.

and also make non-UTF-8 string.const a validation error when stringref is not enabled.

When stringref is disabled, any string.const (UTF8 or otherwise) is invalid anyhow?

string.const should still be valid when string-builtins are enabled. We might want to error in binary writing if they haven't been lowered and stringref is not enabled, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, these are valid options, but they all seem significantly more complex to explain and to use. The readme text would need to be substantially longer.

I don't have a better suggestion for this PR yet, but let's keep thinking here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the contrary, I don't think there's much to explain. As always, we optimize to the extent we can given the enabled features, and we validate that the IR will be written as valid modules given the enabled features

We should document that string.const is valid IR if either of the string features are enabled, but only on the condition that it will be lowered before writing if stringref is disabled. We should also document that string.const containing unpaired surrogates is only valid if stringref is enabled. I don't think we need to document how automatic lifting and lowering works, just as we don't need to document the specifics of what other optimizations we run.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say all of these quotes are non-trivial and potentially confusing for our users:

  • "do the lifting when either stringref or string-builtins are enabled, then lower only if string-builtins and not stringref are enabled"
  • "string.const is valid IR if either of the string features are enabled, but only on the condition that it will be lowered before writing if stringref is disabled"
  • "string.const containing unpaired surrogates is only valid if stringref is enabled."

Just adding that text by itself would double the current PR's readme entry.

I really feel we should find something simpler here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say all of these quotes are non-trivial and potentially confusing for our users:

  • "do the lifting when either stringref or string-builtins are enabled, then lower only if string-builtins and not stringref are enabled"

This is just us doing optimizations based on the target features. It doesn't need to be documented or understood by users.

  • "string.const is valid IR if either of the string features are enabled, but only on the condition that it will be lowered before writing if stringref is disabled"

Yeah, this one is weird. If lowering were automatic in the binary writer, this wouldn't need to be documented or understood, either. This complexity is the price we pay to make lowering a separately sequenced pass.

  • "string.const containing unpaired surrogates is only valid if stringref is enabled."

This one just matches the expressive capabilities of the underlying features. I don't think it needs to be documented beyond error messages.

Just adding that text by itself would double the current PR's readme entry.

I really feel we should find something simpler here.

This is the validation behavior we would want independent of how we lift and lower strings. The only reason this complexity comes up in this PR and not before is because we didn't have separate string features before this PR. But it's strictly more useful to users to have separate string features with detailed validation to ensure they actually produce valid binaries for the intended engine feature set.

}

addIfNoDWARFIssues("remove-unused-module-elements");
if (options.optimizeLevel >= 2 && wasm->features.hasStrings()) {
// Gather strings to globals right before reorder-globals, which will then
Expand Down
21 changes: 19 additions & 2 deletions src/tools/optimization-options.h
Original file line number Diff line number Diff line change
Expand Up @@ -398,7 +398,19 @@ struct OptimizationOptions : public ToolOptions {
passRunner.clear();
};

for (auto& pass : passes) {
// Find the first and last default opt passes, so we can tell them they are
// first/last.
Index firstDefault = passes.size();
Index lastDefault = passes.size();
for (Index i = 0; i < passes.size(); i++) {
if (passes[i].name == DEFAULT_OPT_PASSES) {
firstDefault = std::min(firstDefault, i);
lastDefault = i;
}
}

for (Index i = 0; i < passes.size(); i++) {
auto& pass = passes[i];
if (pass.name == DEFAULT_OPT_PASSES) {
// This is something like -O3 or -Oz. We must run this now, in order to
// set the proper opt and shrink levels. To do that, first reset the
Expand All @@ -416,8 +428,13 @@ struct OptimizationOptions : public ToolOptions {
passRunner.options.optimizeLevel = *pass.optimizeLevel;
passRunner.options.shrinkLevel = *pass.shrinkLevel;

// Note the ordering of these default passes.
PassRunner::Ordering ordering;
ordering.first = (i == firstDefault);
ordering.last = (i == lastDefault);
Comment on lines +432 to +434
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively:

Suggested change
PassRunner::Ordering ordering;
ordering.first = (i == firstDefault);
ordering.last = (i == lastDefault);
PassRunner::Ordering ordering{i == firstDefault, i == lastDefault};

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of like writing out which is first and which is last? I guess the natural order is (first, last) but it is still easier to read I think.


// Run our optimizations now with the custom levels.
passRunner.addDefaultOptimizationPasses();
passRunner.addDefaultOptimizationPasses(ordering);
flush();

// Restore the default optimize/shrinkLevels.
Expand Down
2 changes: 2 additions & 0 deletions src/tools/tool-options.h
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,8 @@ struct ToolOptions : public Options {
.addFeature(FeatureSet::FP16, "float 16 operations")
.addFeature(FeatureSet::CustomDescriptors,
"custom descriptors (RTTs) and exact references")
.addFeature(FeatureSet::StringBuiltins,
"string builtins (imported JS strings)")
.add("--enable-typed-function-references",
"",
"Deprecated compatibility flag",
Expand Down
1 change: 1 addition & 0 deletions src/wasm-binary.h
Original file line number Diff line number Diff line change
Expand Up @@ -454,6 +454,7 @@ extern const char* FP16Feature;
extern const char* BulkMemoryOptFeature;
extern const char* CallIndirectOverlongFeature;
extern const char* CustomDescriptorsFeature;
extern const char* StringBuiltinsFeature;

enum Subsection {
NameModule = 0,
Expand Down
7 changes: 6 additions & 1 deletion src/wasm-features.h
Original file line number Diff line number Diff line change
Expand Up @@ -55,11 +55,12 @@ struct FeatureSet {
// it does nothing. Binaryen always accepts LEB call-indirect encodings.
CallIndirectOverlong = 1 << 20,
CustomDescriptors = 1 << 21,
StringBuiltins = 1 << 22,
MVP = None,
// Keep in sync with llvm default features:
// https://github.com/llvm/llvm-project/blob/c7576cb89d6c95f03968076e902d3adfd1996577/clang/lib/Basic/Targets/WebAssembly.cpp#L150-L153
Default = SignExt | MutableGlobals,
All = (1 << 22) - 1,
All = (1 << 23) - 1,
};

static std::string toString(Feature f) {
Expand Down Expand Up @@ -108,6 +109,8 @@ struct FeatureSet {
return "call-indirect-overlong";
case CustomDescriptors:
return "custom-descriptors";
case StringBuiltins:
return "string-builtins";
case MVP:
case Default:
case All:
Expand Down Expand Up @@ -168,6 +171,7 @@ struct FeatureSet {
bool hasCustomDescriptors() const {
return (features & CustomDescriptors) != 0;
}
bool hasStringBuiltins() const { return (features & StringBuiltins) != 0; }
bool hasAll() const { return (features & All) != 0; }

void set(FeatureSet f, bool v = true) {
Expand All @@ -194,6 +198,7 @@ struct FeatureSet {
void setFP16(bool v = true) { set(FP16, v); }
void setBulkMemoryOpt(bool v = true) { set(BulkMemoryOpt, v); }
void setCustomDescriptors(bool v = true) { set(CustomDescriptors, v); }
void setStringBuiltins(bool v = true) { set(StringBuiltins, v); }
void setMVP() { features = MVP; }
void setAll() { features = All; }

Expand Down
4 changes: 4 additions & 0 deletions src/wasm/wasm-binary.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -1395,6 +1395,8 @@ void WasmBinaryWriter::writeFeaturesSection() {
return BinaryConsts::CustomSections::CallIndirectOverlongFeature;
case FeatureSet::CustomDescriptors:
return BinaryConsts::CustomSections::CustomDescriptorsFeature;
case FeatureSet::StringBuiltins:
return BinaryConsts::CustomSections::StringBuiltinsFeature;
case FeatureSet::None:
case FeatureSet::Default:
case FeatureSet::All:
Expand Down Expand Up @@ -5193,6 +5195,8 @@ void WasmBinaryReader::readFeatures(size_t payloadLen) {
feature = FeatureSet::FP16;
} else if (name == BinaryConsts::CustomSections::CustomDescriptorsFeature) {
feature = FeatureSet::CustomDescriptors;
} else if (name == BinaryConsts::CustomSections::StringBuiltinsFeature) {
feature = FeatureSet::StringBuiltins;
} else {
// Silently ignore unknown features (this may be and old binaryen running
// on a new wasm).
Expand Down
1 change: 1 addition & 0 deletions src/wasm/wasm.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,7 @@ const char* FP16Feature = "fp16";
const char* BulkMemoryOptFeature = "bulk-memory-opt";
const char* CallIndirectOverlongFeature = "call-indirect-overlong";
const char* CustomDescriptorsFeature = "custom-descriptors";
const char* StringBuiltinsFeature = "string-builtins";

} // namespace BinaryConsts::CustomSections

Expand Down
2 changes: 1 addition & 1 deletion test/binaryen.js/kitchen-sink.js.txt
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Features.RelaxedSIMD: 4096
Features.ExtendedConst: 8192
Features.Strings: 16384
Features.MultiMemory: 32768
Features.All: 4194303
Features.All: 8388607
InvalidId: 0
BlockId: 1
IfId: 2
Expand Down
2 changes: 1 addition & 1 deletion test/example/c-api-kitchen-sink.txt
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ BinaryenFeatureMemory64: 2048
BinaryenFeatureRelaxedSIMD: 4096
BinaryenFeatureExtendedConst: 8192
BinaryenFeatureStrings: 16384
BinaryenFeatureAll: 4194303
BinaryenFeatureAll: 8388607
(f32.neg
(f32.const -33.61199951171875)
)
Expand Down
Loading
Loading