On Fri, 24 Nov 2023 at 20:07, Jan Hubicka wrote:
> The vector.tcc change was regtested on x86_64-linux, OK?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/vector.tcc (reserve): Copy _M_start and _M_finish
> to local variables to allow propagation across call to
> allocator.
> With my changes at -O3 we now inline push_back, so we could optimize the
> first loop to the second. However with
> ~/trunk-install/bin/gcc -O3 auto.C -S -fdump-tree-all-details
> -fno-exceptions -fno-store-merging -fno-tree-slp-vectorize
> the fist problem is right at the begining:
>
>[
On Thu, 23 Nov 2023, Jonathan Wakely wrote:
That's why we need -fsane-operator-new
Although the standard forbids it, some of us just provide an inline
implementation
inline void* operator new(std::size_t n){return malloc(n);}
inline void operator delete(void*p)noexcept{free(p);}
inline void
On Fri, 24 Nov 2023, Martin Jambor wrote:
> Hello,
>
> On Thu, Nov 23 2023, Jonathan Wakely wrote:
> > On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
> >>
>
> [...]
>
> >>
> >> I also wonder, if default operator new and malloc can be handled as not
> >> reading/modifying anything visible to
Hello,
On Thu, Nov 23 2023, Jonathan Wakely wrote:
> On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
>>
[...]
>>
>> I also wonder, if default operator new and malloc can be handled as not
>> reading/modifying anything visible to the user code.
>
> No, there's no way to know if the default oper
On Thu, 23 Nov 2023 at 15:44, Jan Hubicka wrote:
>
> Hi,
> so if I understand it right, it should be safe to simply replace memmove
> by memcpy. I wonder if we can get rid of the count != 0 check at least
> for glibc systems.
I don't think we can do that. It's still undefined with glibc, and
gli
On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
>
> > > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > > Sadly it is really hard to work out this
> > > > from IPA passes, since we basically care whether the iterator points to
> > > > the same place as the end pointer, which are
Hi,
so if I understand it right, it should be safe to simply replace memmove
by memcpy. I wonder if we can get rid of the count != 0 check at least
for glibc systems. In general push_back now need inline-insns-auto to
be 33 to be inlined at -O2
jh@ryzen4:/tmp> cat ~/tt.C
#include
typedef unsig
> > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > Sadly it is really hard to work out this
> > > from IPA passes, since we basically care whether the iterator points to
> > > the same place as the end pointer, which are both passed by reference.
> > > This is inter-procedural va
> On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > Sadly it is really hard to work out this
> > from IPA passes, since we basically care whether the iterator points to
> > the same place as the end pointer, which are both passed by reference.
> > This is inter-procedural value number
On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> Sadly it is really hard to work out this
> from IPA passes, since we basically care whether the iterator points to
> the same place as the end pointer, which are both passed by reference.
> This is inter-procedural value numbering that i
On Tue, 21 Nov 2023 at 12:50, Jan Hubicka wrote:
>
> > > + // RAII type to destroy initialized elements.
> >
> > There's only one initialized element, not "elements".
> >
> > > + struct _Guard_elts
> > > + {
> > > + pointer _M_first, _M_last; // Elements
> > + // RAII type to destroy initialized elements.
>
> There's only one initialized element, not "elements".
>
> > + struct _Guard_elts
> > + {
> > + pointer _M_first, _M_last; // Elements to destroy
>
> We only need to store one pointer here, call it
On Mon, 20 Nov 2023 at 15:44, Jan Hubicka wrote:
>
> > > + // RAII type to destroy initialized elements.
> >
> > There's only one initialized element, not "elements".
> >
> > > + struct _Guard_elts
> > > + {
> > > + pointer _M_first, _M_last; // Elements
> > + // RAII type to destroy initialized elements.
>
> There's only one initialized element, not "elements".
>
> > + struct _Guard_elts
> > + {
> > + pointer _M_first, _M_last; // Elements to destroy
>
> We only need to store one pointer here, call it
On Sun, 19 Nov 2023 at 21:53, Jan Hubicka wrote:
>
> Hi,
> this patch speeds up the push_back at -O3 significantly by making the
> reallocation to be inlined by default. _M_realloc_insert is general
> insertion that takes iterator pointing to location where the value
> should be inserted. As suc
16 matches
Mail list logo
