[llvm-bugs] [Bug 52548] New: -O1,2,3 + const inline value = SLOW

[via llvm-bugs]

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

            Bug ID: 52548
           Summary: -O1,2,3 + const inline value = SLOW
           Product: clang
           Version: 2.8
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++17
          Assignee: unassignedclangbugs at nondot.org
          Reporter: johannes.fieres at volumegraphics.com
                CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
                    llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

Created attachment 25458
  --> https://bugs.llvm.org/attachment.cgi?id=25458&action=edit
Reproducing example (cpp file)

Hi,

the c++17 construct "inline const var = initializer;" causes the optimizer to
run very long even if there is nothing obvious to optimize. 

I have prepared a simple test "program" (a.cpp) which does nothing but declare
and initialize 1000 constants in this manner. 

clang++ -std=c++17 -O0 -c a.cpp -o o # takes 0.31 seconds
clang++ -std=c++17 -O1 -c a.cpp -o o # takes 1.14 seconds

Somebody in our company had the idea to change all our global enum header from
"extern const int" (with initialization in a separate source) to "inline const
int" (with initialization in the header). This causes my build times rise from
25 to 40 minutes in Release mode :-( With cl.exe and gcc we see a similar
effect but by far not as severe.

I can see that "inline const int" is much more costly to compile compared to
"extern const int", because you need to be able to deduplicate the constants
and their initialization later.

However, it's obscure to me why the optimizer should have anything to do in the
reproducing example, except to find out that there is nothing to optimize (note
that the initializer function itself is just declared, not defined, in this
example).

Thanks!

-- 
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/20211118/f0fdff82/attachment.html>