Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Jonathan Wakely
On Tue, 26 Nov 2024 at 18:16, Marc Glisse wrote: > > On Tue, 26 Nov 2024, Jonathan Wakely wrote: > > >>> In the bla() example above, the call bla() is a constant expression > >>> when used to initialize a const int, so the compiler is required to > >>> evaluate it at compile time. > >> > >> When u

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Marc Glisse
On Tue, 26 Nov 2024, Jonathan Wakely wrote: In the bla() example above, the call bla() is a constant expression when used to initialize a const int, so the compiler is required to evaluate it at compile time. When used in contexts that doesn't require an integral constant I think a distinction

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Michael Matz
Hello, On Tue, 26 Nov 2024, Jonathan Wakely wrote: > So the 'const int' doesn't really matter for any -On level, as you > say, but just avoiding two separate uses of the __deque_buf_size > function is worthwhile for -std=c++98 -O0 Oh, definitely. Avoiding duplicate calls in C++ sources (no matt

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Jonathan Wakely
On Tue, 26 Nov 2024 at 16:15, Michael Matz wrote: > > Hello, > > thanks for bearing with me :) > > On Tue, 26 Nov 2024, Jonathan Wakely wrote: > > > Being a member function makes no difference, but yes, I'm specifically > > talking about the case of calling a constexpr function. > > > > constexpr

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Michael Matz
Hello, thanks for bearing with me :) On Tue, 26 Nov 2024, Jonathan Wakely wrote: > Being a member function makes no difference, but yes, I'm specifically > talking about the case of calling a constexpr function. > > constexpr int bla() { return 2; } > int foo (void) { > const int x = bla(); >

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Jonathan Wakely
On Tue, 26 Nov 2024 at 14:27, Michael Matz wrote: > > Hello, > > I don't have anything to add to the threads topic itself, but was > triggered by something: > > On Tue, 26 Nov 2024, Jonathan Wakely wrote: > > > > > const size_t __bufsz = __deque_buf_size(sizeof(_Tp)); > > > ... > > > I wonder wh

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Michael Matz
Hello, I don't have anything to add to the threads topic itself, but was triggered by something: On Tue, 26 Nov 2024, Jonathan Wakely wrote: > > > const size_t __bufsz = __deque_buf_size(sizeof(_Tp)); > > ... > > I wonder why "const" is useful here. > > Because if you don't initialize a cons

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Jan Hubicka
> > diff --git a/libstdc++-v3/include/bits/deque.tcc > > b/libstdc++-v3/include/bits/deque.tcc > > index deb010a0ebb..e56cd0b9319 100644 > > --- a/libstdc++-v3/include/bits/deque.tcc > > +++ b/libstdc++-v3/include/bits/deque.tcc > > @@ -955,6 +955,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER > >

Re: improve std::deque::_M_reallocate_map

2024-11-26 Thread Jonathan Wakely
On Tue, 26 Nov 2024 at 12:08, Jan Hubicka wrote: > > > > diff --git a/libstdc++-v3/include/bits/deque.tcc > > > b/libstdc++-v3/include/bits/deque.tcc > > > index deb010a0ebb..e56cd0b9319 100644 > > > --- a/libstdc++-v3/include/bits/deque.tcc > > > +++ b/libstdc++-v3/include/bits/deque.tcc > > > @

Re: improve std::deque::_M_reallocate_map

2024-11-25 Thread Jonathan Wakely
On 24/11/24 16:26 +0100, Jan Hubicka wrote: Hi, looking into reason why we still do throw_bad_alloc in clang binary I noticed that quite few calls come from deque::_M_reallocate_map. This patch adds unreachable to limit the size of realloc_map. _M_reallocate_map is called only if new size is sm

Re: improve std::deque::_M_reallocate_map

2024-11-24 Thread Jan Hubicka
> Hi, > looking into reason why we still do throw_bad_alloc in clang binary I noticed > that quite few calls come from deque::_M_reallocate_map. This patch adds > unreachable to limit the size of realloc_map. _M_reallocate_map is called > only > if new size is smaller then max_size. map is an a

improve std::deque::_M_reallocate_map

2024-11-23 Thread Jan Hubicka
Hi, looking into reason why we still do throw_bad_alloc in clang binary I noticed that quite few calls come from deque::_M_reallocate_map. This patch adds unreachable to limit the size of realloc_map. _M_reallocate_map is called only if new size is smaller then max_size. map is an array holding