Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scalarrepl decimates giant struct #1818

Closed
asl opened this issue May 24, 2007 · 9 comments
Closed

scalarrepl decimates giant struct #1818

asl opened this issue May 24, 2007 · 9 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla code-quality slow-compile

Comments

@asl
Copy link
Collaborator

asl commented May 24, 2007

Bugzilla Link 1446
Resolution FIXED
Resolved on Feb 22, 2010 12:51
Version trunk
OS All
Attachments Testcase (.ll)

Extended Description

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)

@asl
Copy link
Collaborator Author

asl commented May 24, 2007

assigned to @lattner

@asl
Copy link
Collaborator Author

asl commented May 24, 2007

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

@asl
Copy link
Collaborator Author

asl commented May 24, 2007

Scalarrepl ends with tons of GEPs and stores, turning 1K bytecode to 3M monster.

@lattner
Copy link
Collaborator

lattner commented May 24, 2007

Geeze, why so sad about 2500 seconds? :)

I'll take a look, thx

@lattner
Copy link
Collaborator

lattner commented May 24, 2007

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

@asl
Copy link
Collaborator Author

asl commented May 24, 2007

Cheater!

@llvmbot
Copy link
Collaborator

llvmbot commented May 30, 2007

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

@llvmbot
Copy link
Collaborator

llvmbot commented May 30, 2007

Troubling source file

@llvmbot
Copy link
Collaborator

llvmbot commented May 31, 2007

False alarm. Had only recompiled LLVM, not the frontend.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla code-quality slow-compile
Projects
None yet
Development

No branches or pull requests

3 participants