LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1446 - scalarrepl decimates giant struct
Summary: scalarrepl decimates giant struct
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: All All
: P normal
Assignee: Chris Lattner
URL:
Keywords: code-quality, slow-compile
Depends on:
Blocks:
 
Reported: 2007-05-24 08:10 PDT by Anton Korobeynikov
Modified: 2010-02-22 12:51 PST (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
Testcase (.ll) (2.74 KB, text/plain)
2007-05-24 08:10 PDT, Anton Korobeynikov
Details
Troubling source file (45.74 KB, text/plain)
2007-05-30 16:45 PDT, Bram Adams
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Korobeynikov 2007-05-24 08:10:10 PDT
Consider reduced .ll file. It seems, that scalarrepl is cycles.

Steps to reproduce:

./opt -scalarrepl

PS: This is reducion from ioquake3, reported by Bram Adams
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009165.html)
Comment 1 Anton Korobeynikov 2007-05-24 08:10:33 PDT
Created attachment 868 [details]
Testcase (.ll)
Comment 2 Anton Korobeynikov 2007-05-24 08:58:06 PDT
Ohh, it doesn't cycle:

$ ./opt -scalarrepl bugpoint-reduced-simplified.bc -time-passes -disable-output
===-------------------------------------------------------------------------===
                      ... Pass execution timing report ...
===-------------------------------------------------------------------------===
  Total Execution Time: 2565.1610 seconds (2567.9171 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  ---
Name ---
  2564.8470 ( 99.9%)   0.2039 ( 99.5%)  2565.0510 ( 99.9%)  2567.8074 ( 99.9%) 
Scalar Replacement of Aggregates
   0.1089 (  0.0%)   0.0000 (  0.0%)   0.1089 (  0.0%)   0.1095 (  0.0%)  Module
Verifier
   0.0000 (  0.0%)   0.0009 (  0.4%)   0.0009 (  0.0%)   0.0000 (  0.0%) 
Dominator Tree Construction
   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)  ET
Forest Construction
   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%) 
Dominance Frontier Construction
   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)  Target
Data Layout
  2564.9560 (100.0%)   0.2049 (100.0%)  2565.1610 (100.0%)  2567.9171 (100.0%) 
TOTAL
Comment 3 Anton Korobeynikov 2007-05-24 10:35:46 PDT
Scalarrepl ends with tons of GEPs and stores, turning 1K bytecode to 3M monster.
Comment 4 Chris Lattner 2007-05-24 13:33:49 PDT
Geeze, why so sad about 2500 seconds? :)

I'll take a look, thx
Comment 5 Chris Lattner 2007-05-24 13:44:20 PDT
Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/050016.html

Testcase here: Transforms/ScalarRepl/2007-05-24-LargeAggregate.ll

Thanks!

-Chris
Comment 6 Anton Korobeynikov 2007-05-24 13:46:00 PDT
Cheater!
Comment 7 Bram Adams 2007-05-30 16:40:51 PDT
It looks like the fix only works on OSX (PPC), as on Linux X86 the frontend is now stuck inside the for-
loop on lines 176-->391 of PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl:

#4  0x08764f72 in (anonymous namespace)::PromoteMem2Reg::run (this=0xbff9bfa0)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/Utils/
PromoteMemoryToRegister.cpp:271
#5  0x08767021 in llvm::PromoteMemToReg (Allocas=@0xbff9c120, ET=@0x8b14c10, 
DF=@0x8b14d98, AST=0x0)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/Utils/
PromoteMemoryToRegister.cpp:812
#6  0x08744713 in (anonymous namespace)::SROA::performPromotion (this=0x8b14f38, 
F=@0x8bc8468)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/Scalar/
ScalarReplAggregates.cpp:130
#7  0x087445ba in (anonymous namespace)::SROA::runOnFunction (this=0x8b14f38, F=@0x8bc8468)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/Scalar/
ScalarReplAggregates.cpp:101
#8  0x08826499 in llvm::FPPassManager::runOnFunction (this=0x8b15d00, F=@0x8bc8468)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/PassManager.cpp:1145
#9  0x08826237 in llvm::FunctionPassManagerImpl::run (this=0x8b14e78, F=@0x8bc8468)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/PassManager.cpp:1103
#10 0x0882611f in llvm::FunctionPassManager::run (this=0x8b156e8, F=@0x8bc8468)
    at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/PassManager.cpp:1048

Steps to reproduce (new attached file): 

llvm-gcc -emit-llvm  -Wall -fno-strict-aliasing -Wimplicit -Wstrict-prototypes -pipe -DUSE_OPENAL=1 
-DUSE_CURL=1 -DUSE_CURL_DLOPEN=1 -DUSE_SDL_VIDEO=1 -DUSE_SDL_SOUND=1 -I/usr/include/
SDL -D_REENTRANT -m32 -DUSE_LOCAL_HEADERS=1 -DSVN_VERSION=\"1.33_SVN6303:6304\" -
DNDEBUG -O3 -march=i586 -fomit-frame-pointer -ffast-math -funroll-loops -falign-loops=2 -
falign-jumps=2 -falign-functions=2 -fstrength-reduce  -o file.o -c file.c
Comment 8 Bram Adams 2007-05-30 16:45:56 PDT
Created attachment 967 [details]
Troubling source file
Comment 9 Bram Adams 2007-05-31 05:27:29 PDT
False alarm. Had only recompiled LLVM, not the frontend.