* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
@ 2014-07-28 8:51 ` redi at gcc dot gnu.org
2014-08-01 15:27 ` lukeocamden at gmail dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-07-28 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is by design.
I have a patch to do the optimization a bit more aggressively, but still only
for trivially copyable types and others known to be location invariant (which
should include lambdas)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
2014-07-28 8:51 ` [Bug libstdc++/61909] " redi at gcc dot gnu.org
@ 2014-08-01 15:27 ` lukeocamden at gmail dot com
2014-08-01 16:34 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: lukeocamden at gmail dot com @ 2014-08-01 15:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #2 from lukeocamden at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> This is by design.
I don't really follow - do you mean a consequence of the design, or does the
standard mandate copying/moving the object into the heap, or does using the
heap have some other benefit?
> I have a patch to do the optimization a bit more aggressively, but still
> only for trivially copyable types and others known to be location invariant
> (which should include lambdas)
That would be a great start - thanks very much!
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
2014-07-28 8:51 ` [Bug libstdc++/61909] " redi at gcc dot gnu.org
2014-08-01 15:27 ` lukeocamden at gmail dot com
@ 2014-08-01 16:34 ` redi at gcc dot gnu.org
2014-08-04 11:13 ` lukeocamden at gmail dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-08-01 16:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to lukeocamden from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > This is by design.
>
> I don't really follow - do you mean a consequence of the design, or does the
> standard mandate copying/moving the object into the heap, or does using the
> heap have some other benefit?
None of the above.
I mean the author of our std::function intentionally chose to only avoid the
heap for function pointers
/**
* Trait identifying "location-invariant" types, meaning that the
* address of the object (or any of its members) will not escape.
* Also implies a trivial copy constructor and assignment operator.
*/
template<typename _Tp>
struct __is_location_invariant
: __or_<is_pointer<_Tp>, is_member_pointer<_Tp>>::type
{ };
...
static const bool __stored_locally =
(__is_location_invariant<_Functor>::value
&& sizeof(_Functor) <= _M_max_size
&& __alignof__(_Functor) <= _M_max_align
&& (_M_max_align % __alignof__(_Functor) == 0));
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (2 preceding siblings ...)
2014-08-01 16:34 ` redi at gcc dot gnu.org
@ 2014-08-04 11:13 ` lukeocamden at gmail dot com
2014-08-04 11:15 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: lukeocamden at gmail dot com @ 2014-08-04 11:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #4 from lukeocamden at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to lukeocamden from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > This is by design.
> >
> > I don't really follow - do you mean a consequence of the design, or does the
> > standard mandate copying/moving the object into the heap, or does using the
> > heap have some other benefit?
>
> None of the above.
>
> I mean the author of our std::function intentionally chose to only avoid the
> heap for function pointers
>
> /**
> * Trait identifying "location-invariant" types, meaning that the
> * address of the object (or any of its members) will not escape.
> * Also implies a trivial copy constructor and assignment operator.
> */
If this doesn't offer a clear advantage, should I try to come up with a patch
to support small objects too?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (3 preceding siblings ...)
2014-08-04 11:13 ` lukeocamden at gmail dot com
@ 2014-08-04 11:15 ` redi at gcc dot gnu.org
2014-09-12 18:58 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-08-04 11:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I already have a patch to do it
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (4 preceding siblings ...)
2014-08-04 11:15 ` redi at gcc dot gnu.org
@ 2014-09-12 18:58 ` redi at gcc dot gnu.org
2014-10-09 18:18 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-12 18:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-09-12
Ever confirmed|0 |1
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The right fix requires std::is_trivially_copyable, so fixing this properly this
will have to wait until someone implements that.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (5 preceding siblings ...)
2014-09-12 18:58 ` redi at gcc dot gnu.org
@ 2014-10-09 18:18 ` redi at gcc dot gnu.org
2014-10-09 18:35 ` redi at gcc dot gnu.org
2014-10-10 22:20 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-09 18:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Thu Oct 9 18:17:28 2014
New Revision: 216047
URL: https://gcc.gnu.org/viewcvs?rev=216047&root=gcc&view=rev
Log:
PR libstdc++/61909
* include/std/functional (__is_location_invariant): Treat all
trivially copyable types as location invariant.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (6 preceding siblings ...)
2014-10-09 18:18 ` redi at gcc dot gnu.org
@ 2014-10-09 18:35 ` redi at gcc dot gnu.org
2014-10-10 22:20 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-09 18:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
std::function<void()> f3((X())); // abort
This works now, but the lambda still needs to allocate.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/61909] Small function optimization not applied to small objects
2014-07-25 10:47 [Bug libstdc++/61909] New: Small function optimization not applied to small objects lukeocamden at gmail dot com
` (7 preceding siblings ...)
2014-10-09 18:35 ` redi at gcc dot gnu.org
@ 2014-10-10 22:20 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-10 22:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |5.0
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And as of https://gcc.gnu.org/ml/gcc-bugs/2014-10/msg00717.html the lambda case
should also be allocation-free.
^ permalink raw reply [flat|nested] 10+ messages in thread