[PATCH 4/7] libstdc++: Remove indirection to __find_if in std::find etc.

[Jonathan Wakely]

On Wed, 23 Oct 2024 at 18:12, François Dumont <frs.dumont@gmail.com> wrote:
>
>
> On 15/10/2024 16:38, Jonathan Wakely wrote:
> > On 15/10/24 15:20 +0100, Jonathan Wakely wrote:
> >> Tested x86_64-linux.
> >>
> >> -- >8 --
> >>
> >> There doesn't seem to be a lot of benefit in reusing __find_if with
> >> __gnu_cxx::__ops predicates, since they aren't going to actually
> >> instantiate any less code if we use different predicates every time
> >> (e.g. __ops::__negate, or __ops::__iter_equals_val, or
> >> __ops::__pred_iter).
> >>
> >> And now that std::find no longer calls __find_if (because it just does a
> >> loop directly), we can make the _Iter_equals_val case of __find_if call
> >> std::find, to take advantage of its memchr optimization. This benefits
> >> other algos like search_n which use __find_if with _Iter_equals_val.
> >
> > Hmm, I wonder if inverting the relationship below (__find_if calls
> > find, instead of vice versa) can cause an ABI problem if one TU has an
> > instantiation of the old find that calls __find_if, and another TU has
> > an instantiation of the new __find_if that calls find, and they end up
> > calling each other recursively until the stack overflows.
> >
> > We might need to mangle one of them differently.
>
> Or introduce a __find with all the std::find implementation details that
> __find_if will call.
>
> This way you'll also skip the redundant _GLIBCXX_DEBUG checks that this
> version suffer from when using std::find_if.

Ah yes, good suggestion.