On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
> On 06/16/2016 06:40 PM, smaug wrote:
> > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
> >> For
> >>
> >> RefPtr<T> GetFoo() {
> >> RefPtr<T> foo;
> >> // ...
> >> }
> >>
> >> should we:
> >>
> >> 1. return foo and expect RVO to kick in to eliminate additional
> >> AddRef/Release
> >> 2. return foo.forget()
> >> 3. return Move(foo)
> >>
> >> Which one is preferred?
> >>
> >> ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is
> >> also true for other compilers.
> >>
> >
> > Can we somehow guarantee that RVO kicks in? It feels quite error prone to
> > rely on compiler optimization when dealing with
> > possibly slow Addref/Release calls.
> > https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support
> > hints that there are cases when RVO might not happen.
> >
>
> I've been told we can't guarantee RVO to kick in, which means, I think, that
> we should assume we don't have RVO ever and need to
> rely on other coding patterns which are guaranteed to optimize out extra
> addref/release.
> Currently having already_AddRefed as the return type is one such pattern.
>
> What are the other options?
>
>
> At least we can't start using RefPtr<T> as return type before we know it
> won't be causing performance regressions.
> So I would recommend using already_AddRefed for now.
>From what *I* understand, RVO is guaranteed (or at least supported
>everywhere?) when there is only one stack variable that is returned, e.g.:
C foo()
{
C rv;
// ... (put stuff in rv)
return rv;
}
In this case, the caller function stack can host 'rv' directly, no copies
needed.
RVO won't happen when there may be multiple variables in the function, only one
of which will be returned, e.g.:
C foo()
{
C rv1, rv2; bool b;
// ... (assign a value to b)
return b ? rv1 : rv2;
}
The caller cannot know which of rv1 or rv2 will be returned, so no return value
can be lifted.
(Any actual expert who knows the truth?)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
