search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

-O1,2,3 + const inline value = SLOW #51515

Open Quuxplusone opened 3 years ago

Quuxplusone commented 3 years ago
Bugzilla Link PR52548
Status NEW
Importance P enhancement
Reported by Johannes Fieres (johannes.fieres@volumegraphics.com)
Reported on 2021-11-18 07:30:29 -0800
Last modified on 2021-11-18 07:34:40 -0800
Version 2.8
Hardware Macintosh MacOS X
CC blitzrakete@gmail.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments a.cpp (31904 bytes, text/plain)
Blocks
Blocked by
See also 
Created attachment 25458
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!
Quuxplusone commented 3 years ago

Attached a.cpp (31904 bytes, text/plain): Reproducing example (cpp file)

Quuxplusone commented 3 years ago

I should note that I am using Apple clang version 13.0.0 (clang-1300.0.29.3). Only Apple knows which clang/llvm version this is branched from. If you can't reproduce with a recent clang, the problem is already fixed.