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
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 such it contains code to move other entries around
that is quite
17 matches
Mail list logo
