[LLVMbugs] [Bug 23818] New: Function not inlined when it should probably be

[bugzilla-daemon at llvm.org]

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

            Bug ID: 23818
           Summary: Function not inlined when it should probably be
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ldionne.2 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 14462
  --> https://llvm.org/bugs/attachment.cgi?id=14462&action=edit
Minimal working example

Hi,

I have run into a situation[1] where a function should probably be inlined 
but it isn't, resulting in very suboptimal code to be generated. The gist 
of the problem goes as follows:

    auto f() {
        return /* 
            some very large structure which is quite complicated to 
            construct, but which can also be constructed as a constant
            expression. In other words, the expression in the return 
            statement, while being complex, is only composed of constant
            expressions.
         */;
    }

    int main() {
        // In the generated assembly, the code for `f` is generated, which
        // is O.K. because `f` has external linkage. That assembly is pretty  
        // bad, since it has to pass the huge structure returned by f by 
        // value, which spills.
        //
        // However, this call right here to `f()` is not optimized away. 
        // In other words, even though the definition of `f` is visible
        // to the optimizer, `f` is called, resulting in the awful code
        // to be executed. 
        //
        // If `f` is marked as inline, the call is optimized to nothing
        // (and the code of f is not even generated).
        f();
    }


A minimal working example with comments is attached. I realize this is 
a quality of implementation issue more than an actual bug, but I think 
my actual use case[1] justifies at least looking into the problem.


Regards,
Louis

[1]: http://article.gmane.org/gmane.comp.lib.boost.devel/261035

-- 
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/20150611/6fa799b7/attachment.html>