Skip to content

ConstraintAnalysis: Remove older redundant constraints#8912

Merged
kripken merged 3 commits into
WebAssembly:mainfrom
kripken:constraint.deredundant
Jul 17, 2026
Merged

ConstraintAnalysis: Remove older redundant constraints#8912
kripken merged 3 commits into
WebAssembly:mainfrom
kripken:constraint.deredundant

Conversation

@kripken

@kripken kripken commented Jul 15, 2026

Copy link
Copy Markdown
Member

If we know x != 1 and we are told x == 0, then we can forget about
x != 1 and just store x == 0 (which implies x != 1).

@kripken
kripken requested a review from a team as a code owner July 15, 2026 20:13
@kripken
kripken requested review from tlively and removed request for a team July 15, 2026 20:13
Comment thread src/ir/constraint.cpp
for (auto& existing : *this) {
auto result = provesPair(c, existing);
if (result == True) {
existing = c;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We'll have to remove existing and insert c to maintain the expected sorting of constraints.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Good catch, that other PR landed already...

I added a sort operation here.

@kripken
kripken merged commit 1377e42 into WebAssembly:main Jul 17, 2026
15 of 16 checks passed
@kripken
kripken deleted the constraint.deredundant branch July 17, 2026 14:09
@sbc100

sbc100 commented Jul 17, 2026

Copy link
Copy Markdown
Member

I think this change is somehow breaking the binaryen roller:

/Volumes/Work/s/w/ir/cache/builder/emscripten-releases/build/temp/libcxx-install/include/c++/v1/__algorithm/sift_down.h:49:46: error: type 'wasm::inplace_vector<wasm::constraint::Constraint, 3>::Iterator' does not provide a subscript operator

https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8676022167312317953/+/u/Build_Binaryen/stdout

At least it seems to be the only change in the broken roll.

@sbc100

sbc100 commented Jul 17, 2026

Copy link
Copy Markdown
Member

AI created fix: #8916

sbc100 added a commit that referenced this pull request Jul 17, 2026
`ParentIndexIterator` declares `using iterator_category =`
`std::random_access_iterator_tag;`, but did not provide the subscript
operator (`operator[]`) or friend commutative addition
(`friend operator+(difference_type, const ParentIndexIterator&)`).

When `ConstraintAnalysis: Remove older redundant constraints` (#8912)
introduced `std::sort(begin(), end())` on `AndedConstraintSet` (which
inherits from `inplace_vector`), building `binaryen` failed on the
Chromium `emscripten-releases` macOS builders with:

  error: type 'wasm::inplace_vector<...>::Iterator' does not provide
  a subscript operator

This failure did not show up on Binaryen's CI because `libstdc++`
implements `std::sort` using pointer/iterator addition and dereferencing
(`*(first + child)`). In contrast, on macOS with `-stdlib=libc++`,
`libc++` implements `std::sort` (`std::__sift_down`) using
`__first[__child]` and `__first[__start]`, which requires `operator[]`.

This commit adds `decltype(auto) operator[]` and `friend operator+` to
`ParentIndexIterator` to satisfy `RandomAccessIterator` requirements.

Are we missing CI testing for stdlib=libc++?
sbc100 added a commit that referenced this pull request Jul 17, 2026
`ParentIndexIterator` declares `using iterator_category =`
`std::random_access_iterator_tag;`, but did not provide the subscript
operator (`operator[]`) or friend commutative addition
(`friend operator+(difference_type, const ParentIndexIterator&)`).

When `ConstraintAnalysis: Remove older redundant constraints` (#8912)
introduced `std::sort(begin(), end())` on `AndedConstraintSet` (which
inherits from `inplace_vector`), building `binaryen` failed on the
Chromium `emscripten-releases` macOS builders with:

  error: type 'wasm::inplace_vector<...>::Iterator' does not provide
  a subscript operator

This failure did not show up on Binaryen's CI because `libstdc++`
implements `std::sort` using pointer/iterator addition and dereferencing
(`*(first + child)`). In contrast, on macOS with `-stdlib=libc++`,
`libc++` implements `std::sort` (`std::__sift_down`) using
`__first[__child]` and `__first[__start]`, which requires `operator[]`.

This commit adds `decltype(auto) operator[]` and `friend operator+` to
`ParentIndexIterator` to satisfy `RandomAccessIterator` requirements.

Are we missing CI testing for stdlib=libc++?
sbc100 added a commit that referenced this pull request Jul 17, 2026
`ParentIndexIterator` declares `using iterator_category =`
`std::random_access_iterator_tag;`, but did not provide the subscript
operator (`operator[]`) or friend commutative addition
(`friend operator+(difference_type, const ParentIndexIterator&)`).

When `ConstraintAnalysis: Remove older redundant constraints` (#8912)
introduced `std::sort(begin(), end())` on `AndedConstraintSet` (which
inherits from `inplace_vector`), building `binaryen` failed on the
Chromium `emscripten-releases` macOS builders with:

  error: type 'wasm::inplace_vector<...>::Iterator' does not provide
  a subscript operator

This failure did not show up on Binaryen's CI because `libstdc++`
implements `std::sort` using pointer/iterator addition and dereferencing
(`*(first + child)`). In contrast, on macOS with `-stdlib=libc++`,
`libc++` implements `std::sort` (`std::__sift_down`) using
`__first[__child]` and `__first[__start]`, which requires `operator[]`.

This commit adds `decltype(auto) operator[]` and `friend operator+` to
`ParentIndexIterator` to satisfy `RandomAccessIterator` requirements.

Are we missing CI testing for stdlib=libc++?
sbc100 added a commit that referenced this pull request Jul 18, 2026
`ParentIndexIterator` declares `using iterator_category =`
`std::random_access_iterator_tag;`, but did not provide the subscript
operator (`operator[]`) or friend commutative addition
(`friend operator+(difference_type, const ParentIndexIterator&)`).

When `ConstraintAnalysis: Remove older redundant constraints` (#8912)
introduced `std::sort(begin(), end())` on `AndedConstraintSet` (which
inherits from `inplace_vector`), building `binaryen` failed on the
Chromium `emscripten-releases` macOS builders with:

  error: type 'wasm::inplace_vector<...>::Iterator' does not provide
  a subscript operator

This failure did not show up on Binaryen's CI because `libstdc++`
implements `std::sort` using pointer/iterator addition and dereferencing
(`*(first + child)`). In contrast, on macOS with `-stdlib=libc++`,
`libc++` implements `std::sort` (`std::__sift_down`) using
`__first[__child]` and `__first[__start]`, which requires `operator[]`.

This commit adds `decltype(auto) operator[]` and `friend operator+` to
`ParentIndexIterator` to satisfy `RandomAccessIterator` requirements.

Are we missing CI testing for stdlib=libc++?
sbc100 added a commit that referenced this pull request Jul 18, 2026
#8916)

`ParentIndexIterator` declares `using iterator_category =`
`std::random_access_iterator_tag;`, but did not provide the subscript
operator (`operator[]`) or friend commutative addition (`friend
operator+(difference_type, const ParentIndexIterator&)`).

When #8912 introduced `std::sort(begin(), end())` on
`AndedConstraintSet` (which inherits from `inplace_vector`), building
`binaryen` failed on the Chromium `emscripten-releases` macOS builders
with:

```
  error: type 'wasm::inplace_vector<...>::Iterator' does not provide a subscript operator
```

This failure did not show up on Binaryen's CI because `libstdc++`
implements `std::sort` using pointer/iterator addition and dereferencing
(`*(first + child)`). In contrast, on macOS with `-stdlib=libc++`,
`libc++` implements `std::sort` (`std::__sift_down`) using
`__first[__child]` and `__first[__start]`, which requires `operator[]`.

This commit adds `decltype(auto) operator[]` and `friend operator+` to
`ParentIndexIterator` to satisfy `RandomAccessIterator` requirements.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants