[llvm-bugs] [Bug 41491] New: Bad inlining decision when caller puts on stack bunch of unused in callee data (boost::variant visitation)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41491

            Bug ID: 41491
           Summary: Bad inlining decision when caller puts on stack bunch
                    of unused in callee data (boost::variant visitation)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: nok.raven at gmail.com
                CC: llvm-bugs at lists.llvm.org
            Blocks: 4931

boost::variant visitation recursively wraps visitor reference about 3 times.
LLVM decides to not inline even relatively-small switches, leaving switch in
one function and all visitor wrapping in another. Because of that it cannot
optimize-out those wrappers and produces bunch of store/loads.

I don't know whether GCC is more clever or aggressive, but it will inline the
switch even a huge one. https://godbolt.org/z/R6NpPa


// Removes switch bloat due to std::abort, will be part of Boost 1.71
#define BOOST_VARIANT_DETAIL_FORCED_RETURN_HPP
namespace boost { namespace detail { namespace variant {
template <typename T> T forced_return() { __builtin_unreachable(); }
}}}

#include <boost/variant.hpp>

struct A {}; struct B {}; struct C {};
struct D {}; struct E {}; struct F {};
struct G {}; struct H {}; struct J {};

template <typename T> void f(T);

struct Visitor
{
    template <typename T> void operator()(T v) const { f(v); }
};

void foo(boost::variant<A, B, C, D, E, F, G, H, J> v)
{
    boost::apply_visitor(Visitor{}, v);
}


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=4931
[Bug 4931] [meta] Improve inlining effectiveness
-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190414/0b56463c/attachment.html>