[LLVMbugs] [Bug 15552] New: Poor constexpr performance vs gcc

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Mar 20 10:23:13 PDT 2013


http://llvm.org/bugs/show_bug.cgi?id=15552

            Bug ID: 15552
           Summary: Poor constexpr performance vs gcc
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: antoinep92 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code (fibbonacci sequence at compile time) takes serveral minutes
to compile, as opposed to less than 0.1s with gcc.
Also both clang and gcc take less than 0.1s to compile the equivalent written
with templates.

I'm not familiar enough with clang internals to be sure, but I guess template
instanciation has a better cache size/strategy than constexpr recursion. Maybe
the cache in place for templates could be reused for constexpr?

To test, compile both codes bellow with
  clang++ -std=c++11 -fconstexpr-depth=65536
_______________
// very, very long computation with clang but not gcc
typedef unsigned long long ul;
constexpr ul fib(ul n) { return n < 2 ? n : fib(n-2) + fib(n-1); }
static_assert(fib(93) == 12200160415121876738ul, "bad result");

_______________
// fast with both clang and gcc
typedef unsigned long long ul;
template<ul n> struct fib {
        static const ul value = fib<n-2>::value + fib<n-1>::value;
};
template<> struct fib<1> {
        static const ul value = 1;
};
template<> struct fib<0> {
        static const ul value = 0;
};
static_assert(fib<93>::value == 12200160415121876738ul, "bad result");

-- 
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/20130320/748cd8b6/attachment.html>


More information about the llvm-bugs mailing list