| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 148219
|
| |
|
|
|
|
| |
CodeGen.
llvm-svn: 148218
|
| |
|
|
| |
llvm-svn: 148217
|
| |
|
|
| |
llvm-svn: 148216
|
| |
|
|
|
|
|
|
|
| |
std::map, since we need to keep a valid pointer to properties of current loop.
Message for r148132:
LoopUnswitch: All helper data that is collected during loop-unswitch iterations was moved to separated class (LUAnalysisCache).
llvm-svn: 148215
|
| |
|
|
|
|
|
| |
we're loading from the global array, not how it is spelled in the asm.
This should fix the MSVC bots.
llvm-svn: 148214
|
| |
|
|
|
|
| |
removal desired.
llvm-svn: 148213
|
| |
|
|
|
|
|
|
|
|
| |
re-computed rather than the variables be re-used just after the assert.
Just use the variables since we have them already. Fixes an unused
variable warning.
Also fix an 80-column violation.
llvm-svn: 148212
|
| |
|
|
|
|
|
|
|
|
|
|
| |
or Clang is using this, and it would be hard to use it correctly given
the thread hostility of the function. Also, it never checked the return
which is rather dangerous with chdir. If someone was in fact using this,
please let me know, as well as what the usecase actually is so that
I can add it back and make it more correct and secure to use. (That
said, it's never going to be "safe" per-se, but we could at least
document the risks...)
llvm-svn: 148211
|
| |
|
|
|
|
|
| |
Don't consider decltype(e) for an instantiation-dependent, but not
type-dependent, e to be non-type-dependent but canonical(!).
llvm-svn: 148210
|
| |
|
|
|
|
|
|
| |
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.
llvm-svn: 148209
|
| |
|
|
|
|
|
| |
designator invalid. (Since we can't read the value of such a pointer, this only
affects the quality of diagnostics.)
llvm-svn: 148208
|
| |
|
|
|
|
|
|
| |
or VarDecl::isExternC, and instead queries what it actually cares about: whether the given declaration is inside an extern "C" context. Fundamentally, figuring out whether a function/variable uses C linkage requires knowing the linkage, and the logic in FunctionDecl::isExternC and VarDecl::isExternC was getting it wrong. Given that, fix FunctionDecl::isExternC and VarDecl::isExternC to use much simpler implementations that depend on the fixed linkage computation.
Fixes a regression to test/SemaCXX/linkage.cpp caused by a new warning exposing the fact that the internal state was wrong.
llvm-svn: 148207
|
| |
|
|
| |
llvm-svn: 148206
|
| |
|
|
| |
llvm-svn: 148205
|
| |
|
|
|
|
| |
Shrinks OverloadCandidate from 208 to 168 bytes.
llvm-svn: 148204
|
| |
|
|
| |
llvm-svn: 148202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed two double "int close(int fd)" issues found by our file descriptor
interposing library on darwin:
The first is in SBDebugger::SetInputFileHandle (FILE *file, bool transfer_ownership)
where we would give our FILE * to a lldb_private::File object member variable and tell
it that it owned the file descriptor if "transfer_ownership" was true, and then we
would also give it to the communication plug-in that waits for stdin to come in and
tell it that it owned the FILE *. They would both try and close the file.
The seconds was when we use a file descriptor through ConnectionFileDescriptor
where someone else is creating a connection with ConnectionFileDescriptor and a URL
like: "fd://123". We were always taking ownwership of the fd 123, when we shouldn't
be. There is a TODO in the comments that says we should allow URL options to be passed
to be able to specify this later (something like: "fd://123?transer_ownership=1"), but
we can get to this later.
llvm-svn: 148201
|
| |
|
|
|
|
| |
fragile.
llvm-svn: 148200
|
| |
|
|
|
|
| |
should fix builds.
llvm-svn: 148199
|
| |
|
|
|
|
| |
conversion sequences so we don't get double frees when the vector reallocates.
llvm-svn: 148198
|
| |
|
|
| |
llvm-svn: 148197
|
| |
|
|
|
|
| |
f128mem instead of f256mem.
llvm-svn: 148196
|
| |
|
|
|
|
|
| |
- don't strip too many frames from the backtrace when logging close backtraces
- cleanup some logging messages
llvm-svn: 148195
|
| |
|
|
|
|
| |
alignment on 256-bit AVX2 instructions.
llvm-svn: 148194
|
| |
|
|
| |
llvm-svn: 148193
|
| |
|
|
| |
llvm-svn: 148192
|
| |
|
|
|
|
|
|
| |
non-determinism in the 32 bit dragonegg buildbot. Original commit
message:
Only emit the Leh_func_endN symbol when needed.
llvm-svn: 148191
|
| |
|
|
| |
llvm-svn: 148190
|
| |
|
|
|
|
|
| |
When the lldb_private::Debugger goes away, it should cleanup all
of its targets.
llvm-svn: 148189
|
| |
|
|
| |
llvm-svn: 148188
|
| |
|
|
|
|
|
|
|
|
|
|
| |
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
llvm-svn: 148187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid malloc thrashing give OverloadCandidateSet an inline capacity for conversion sequences.
We use the fact that OverloadCandidates never outlive the OverloadCandidateSet and have a fixed
amount of conversion sequences.
This eliminates the oversized SmallVector from OverloadCandidate shrinking it from 752 to 208 bytes.
On the test case from the "Why is CLANG++ so freaking slow" thread on llvmdev this avoids one gig
of vector reallocation (including memcpy) which translates into 5-10% speedup on Lion/x86_64.
Overload candidate computation is still the biggest malloc contributor when compiling templated
c++ code.
llvm-svn: 148186
|
| |
|
|
|
|
|
| |
Replace push_back with addCandidate which will let us make use of the fixed size of
the conversion sequence vector soon.
llvm-svn: 148185
|
| |
|
|
|
|
|
|
| |
virtual functions that provide previous/most recent redeclaration
information for any declaration. Use this to eliminate the redundant,
less efficient getPreviousDecl() functions.
llvm-svn: 148184
|
| |
|
|
| |
llvm-svn: 148183
|
| |
|
|
|
|
| |
RedeclarableTemplateDecl. It is not clear that it's worth delaying the allocation of said pointer
llvm-svn: 148182
|
| |
|
|
|
|
|
|
|
|
|
| |
Redeclarable<RedeclarableTemplateDecl>, eliminating a bunch of
redeclaration-chain logic both in RedeclarableTemplateDecl and
especially in its (de-)serialization.
As part of this, eliminate the RedeclarableTemplate<> class template,
which was an abstraction that didn't actually save anything.
llvm-svn: 148181
|
| |
|
|
| |
llvm-svn: 148180
|
| |
|
|
| |
llvm-svn: 148179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APValue::Array and APValue::MemberPointer. All APValue values can now be emitted
as constants.
Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other
entrypoints dealing with constant member pointers are no longer necessary and
will be removed in a later change.
Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to
VarDecl::evaluateValue. This performs caching and deals with the nasty cases in
C++11 where a non-const object's initializer can refer indirectly to
previously-initialized fields within the same object.
Building the intermediate APValue object incurs a measurable performance hit on
pathological testcases with huge initializer lists, so we continue to build IR
directly from the Expr nodes for array and record types outside of C++11.
llvm-svn: 148178
|
| |
|
|
|
|
| |
Fixes PR11761: bad IR w/ redundant Phi elim
llvm-svn: 148177
|
| |
|
|
|
|
| |
data.
llvm-svn: 148176
|
| |
|
|
| |
llvm-svn: 148175
|
| |
|
|
| |
llvm-svn: 148174
|
| |
|
|
| |
llvm-svn: 148173
|
| |
|
|
| |
llvm-svn: 148172
|
| |
|
|
| |
llvm-svn: 148171
|
| |
|
|
|
|
| |
be split up later.
llvm-svn: 148170
|
| |
|
|
|
|
| |
index parameters.
llvm-svn: 148169
|