For the record, this small change have been committed as part of another
larger one:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bcc8dea6a45b46febfa76df6f5e3e5b13f3b4a58
On 19/02/2025 13:49, Jonathan Wakely wrote:
On Mon, 17 Feb 2025 at 11:59, François Dumont <frs.dum...@gmail.com> wrote:
On 16/02/2025 23:14, Jonathan Wakely wrote:
On Sun, 16 Feb 2025 at 21:15, François Dumont <frs.dum...@gmail.com> wrote:
Hi
A minor simplification.
libstdc++: Simplify _Hashtable::_M_merge_multi
When merging two hashtable instances of the same type we do not need
to go through _M_src_hash_code that also check for identical Hash functor
type.
But that check is very cheap, do we really gain much here?
No runtime gain no, just limit instantiations.
If we're getting rid of _M_src_hash_code in this overload of
_M_merge_multi, should we get rid of it in the other overload too,
since that's the only other place that uses _M_src_hash_code?
Seems complicated, so maybe we can avoid is_same_v and is_empty_v with
this smaller patch ?
is_same_v and is_empty_v are extremely cheap, they are variable
templates that use a compiler intrinsic.
libstdc++: [_Hashtable] Avoid is_same_v and is_empty_v instantiations
There is no need to check for same Hash functor type and this type
being stateless
if there is no hash code cached to reuse.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hashtable<>::_M_src_hash_code):
Add __hash_cached::value check.
Let me know if interested.
OK for trunk
