diff options
| author | Bob Wilson <bob.wilson@apple.com> | 2013-07-27 21:59:57 +0000 |
|---|---|---|
| committer | Bob Wilson <bob.wilson@apple.com> | 2013-07-27 21:59:57 +0000 |
| commit | 57217350257d1f455528693d7529fae32f1dad99 (patch) | |
| tree | da0be745bc2553655879d541b0cfc5f0df10f2c4 /llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | |
| parent | b0e688e87ca7aad688f594bafa0c55a47c64ea3b (diff) | |
| download | bcm5719-llvm-57217350257d1f455528693d7529fae32f1dad99.tar.gz bcm5719-llvm-57217350257d1f455528693d7529fae32f1dad99.zip | |
Reduce stack frame size by avoiding a large token vector on an error path.
Beginning with svn r186971, we noticed an internal test started to fail when
using clang built with LTO. After much investigation, it turns out that there
are no blatant bugs here, we are just running out of stack space and crashing.
Preprocessor::ReadFunctionLikeMacroArgs already has one vector of 64 Tokens,
and r186971 added another. When built with LTO, that function is inlined into
Preprocessor::HandleMacroExpandedIdentifier, which for our internal test is
invoked in a deep recursive cycle. I'm leaving the original 64 Token vector
alone on the assumption that it is important for performance, but the new
FixedArgTokens vector is only used on an error path, so it should be OK if it
requires additional heap storage. It would be even better if we could avoid
the deep recursion, but I think this change is a good thing to do regardless.
<rdar://problem/14540345>
llvm-svn: 187315
Diffstat (limited to 'llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp')
0 files changed, 0 insertions, 0 deletions
