[cfe-dev] Inlined function that pass POD by reference

[Reid Kleckner via cfe-dev]

LLVM has an argument promotion pass that does this exact transform, but it
only works on internal functions.

Unfortunately, functions with vague linkage all need to have the same
prototype across all TUs, so we can't do this transform to a function
without internalizing it. We should only internalize small functions, which
are typically good candidates for inlining, which makes the exercise kind
of pointless.

In theory, C++ programmers could create and use a type trait that indicates
that pass-by-value is more efficient for a type than
pass-by-const-reference. However, that would probably make really
complicated code, so I wouldn't suggest it.

On Wed, Jan 11, 2017 at 1:49 AM, Francois Fayard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> Because of the emphasis on generic programming, the C++ standard library
> has many weird signatures such as:
>
> const int& std::min(const int& a, const int& b) (1)
>
> where one would expect a:
>
> int std::min(int a, int b) (2)
>
> I thought that this would not matter from a performance point of view as
> those functions are inlined anyway. And it turns out that when you replace
> a signature such as (2) into (1) where the function is inlined, the
> assembly does not change at the call site: both are inlined properly.
>
> But I came to realize that some side effects are cascaded to other parts
> of the code, and codes that use (1) end up being slower than code using
> (2), wether the compiler is clang, gcc or intel compiler (even though the
> loss of performance differs from compiler to compiler).
>
> Is there any fundamental reason for this? Would you recommend avoiding
> signatures such as (1) which end up being used a lot when min is
> template-defined?
>
> Best regards,
> Francois
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170111/415b2eaf/attachment.html>