| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 160852
|
| |
|
|
| |
llvm-svn: 160851
|
| |
|
|
| |
llvm-svn: 160850
|
| |
|
|
| |
llvm-svn: 160849
|
| |
|
|
| |
llvm-svn: 160848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
|
| |
|
|
|
|
|
|
|
|
|
| |
We were treating this like a CXXDefaultArgExpr, but
SubstNonTypeTemplateParmExpr actually appears when a template is
instantiated, i.e. we have all the information necessary to evaluate it.
This allows us to inline functions like llvm::array_lengthof.
<rdar://problem/11949235>
llvm-svn: 160846
|
| |
|
|
|
|
|
|
| |
It's a good thing CallEvents aren't created all over the place yet.
I checked all the uses this time and the private copy constructor
/really/ shouldn't cause any more problems.
llvm-svn: 160845
|
| |
|
|
|
|
|
|
|
|
|
| |
These tables were indexed by [register][subreg index] which made them,
very large and sparse.
Replace them with lists of sub-register indexes that match the existing
lists of sub-registers. MCRI::getSubReg() becomes a very short linear
search, like getSubRegIndex() already was.
llvm-svn: 160843
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that the weird X86 sub_ss and sub_sd sub-register indexes are gone,
there is no longer a need for the CompositeIndices construct in .td
files. Sub-register index composition can be specified on the
SubRegIndex itself using the ComposedOf field.
Also enforce unique names for sub-registers in TableGen. The same
sub-register cannot be available with multiple sub-register indexes.
llvm-svn: 160842
|
| |
|
|
|
|
|
| |
replace uses of function getMaxCallFrameSize defined in MipsFunctionInfo with
the one MachineFrameInfo has.
llvm-svn: 160841
|
| |
|
|
|
|
|
| |
Passing a temporary via reference parameter still requires a visible
copy constructor.
llvm-svn: 160840
|
| |
|
|
|
|
|
|
| |
retainable types in arc, only suggest CFBridgingRelease/
CFBridgingRetain and not the confusing __bridge casts.
// rdar://11923822
llvm-svn: 160839
|
| |
|
|
|
|
| |
vector
llvm-svn: 160835
|
| |
|
|
| |
llvm-svn: 160833
|
| |
|
|
|
|
| |
I'll remove these two sub-register indexes shortly.
llvm-svn: 160831
|
| |
|
|
|
|
|
|
| |
The (COPY_TO_REGCLASS GR32:$src, VR128) pattern looks odd, but
copyPhysReg does the right thing with it. (The old pattern would
eventually produce the same cross-class copy).
llvm-svn: 160830
|
| |
|
|
|
|
|
|
|
|
|
| |
information if we're not stopped. This could try to read registers
etc when the process is still running and debug builds of lldb would
assert down in GDBRemoteRegisterContext.cpp ReadRegisterBytes because
we couldn't get the sequence mutex for talking to the remote system.
Non-debug builds would just silently fail when doing this.
<rdar://problem/11941758>
llvm-svn: 160829
|
| |
|
|
|
|
| |
their operand
llvm-svn: 160823
|
| |
|
|
| |
llvm-svn: 160822
|
| |
|
|
|
|
|
| |
- "cocoa" was moved to "osx.cocoa" a long time ago.
- "cplusplus" would be a valid package except we don't have any C++ checkers.
llvm-svn: 160821
|
| |
|
|
|
|
|
| |
This gets rid of some more INSERT_SUBREG - IMPLICIT_DEF patterns,
simplifying the emitted code a bit.
llvm-svn: 160820
|
| |
|
|
|
|
|
|
|
|
|
| |
ExprEngine::VisitGuardedExpr
instead of walking to the preceding PostStmt node. There are cases where the last evaluated
expression does not appear in the ExplodedGraph.
Fixes PR 13466.
llvm-svn: 160819
|
| |
|
|
|
|
|
|
|
| |
The SUBREG_TO_REG instruction has magic semantics asserting that the
source value was defined by an instruction that cleared the high half of
the register. Those semantics are never actually exploited for xmm
registers.
llvm-svn: 160818
|
| |
|
|
|
|
|
|
| |
After discussion, the type-based dispatch was decided to be bad for
maintenance and made it very easy for subtle bugs to creep in. Instead,
we'll just be very careful when we do have to allocate these on the heap.
llvm-svn: 160817
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
These idempotent sub-register indices don't do anything --- They simply
map XMM registers to themselves. They no longer affect register classes
either since the SubRegClasses field has been removed from Target.td.
This patch replaces XMM->XMM EXTRACT_SUBREG and INSERT_SUBREG patterns
with COPY_TO_REGCLASS patterns which simply become COPY instructions.
The number of IMPLICIT_DEF instructions before register allocation is
reduced, and that is the cause of the test case changes.
llvm-svn: 160816
|
| |
|
|
| |
llvm-svn: 160815
|
| |
|
|
|
|
| |
backends that use i32/i64 vectors for the getSetCCResultType function.
llvm-svn: 160814
|
| |
|
|
|
|
|
| |
Function names should be camel case, and start with a lower case letter. No
functional change intended.
llvm-svn: 160813
|
| |
|
|
| |
llvm-svn: 160812
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our BugReporter knows how to deal with implicit statements: it looks in
the ParentMap until it finds a parent with a valid location. However, since
initializers are not in the body of a constructor, their sub-expressions are
not in the ParentMap. That was easy enough to fix in AnalysisDeclContext.
...and then even once THAT was fixed, there's still an extra funny case
of Objective-C object pointer fields under ARC, which are initialized with
a top-level ImplicitValueInitExpr. To catch these cases,
PathDiagnosticLocation will now fall back to the start of the current
function if it can't find any other valid SourceLocations. This isn't great,
but it's miles better than a crash.
(All of this is only relevant when constructors and destructors are being
inlined, i.e. under -cfg-add-initializers and -cfg-add-implicit-dtors.)
llvm-svn: 160810
|
| |
|
|
|
|
|
|
| |
This workaround is fairly lame: we simulate the first element's constructor
and destructor and rely on the region invalidation to "initialize" the rest
of the elements.
llvm-svn: 160809
|
| |
|
|
|
|
|
| |
This uses CFG to tell if a constructor call is for a member, and uses
the member's region appropriately.
llvm-svn: 160808
|
| |
|
|
|
|
|
|
|
| |
Previously we were using ParentMap and crawling through the parent DeclStmt.
This should be at least slightly cheaper (and is also more flexible).
No (intended) functionality change.
llvm-svn: 160807
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.
This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).
llvm-svn: 160806
|
| |
|
|
|
|
|
| |
Test case in the next commit, which enables destructors under certain
circumstances.
llvm-svn: 160805
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
llvm-svn: 160804
|
| |
|
|
|
|
|
| |
At the very least this means initializer nodes for constructors and
automatic object destructors are present in the CFG.
llvm-svn: 160803
|
| |
|
|
|
|
|
| |
This avoids an assertion crash when we invalidate on a destructor call
instead of inlining it.
llvm-svn: 160802
|
| |
|
|
| |
llvm-svn: 160801
|
| |
|
|
|
|
| |
Fallout from CmpRuns.py API changes in r160314.
llvm-svn: 160800
|
| |
|
|
|
|
|
|
|
| |
linux. On my eglibc 2.13 based Debian system 'getc' is a macro defined in
/usr/include/stdio.h. This decision to make it a macro doesn't seem to
be guarded by any feature test macro as far as I can see.
llvm-svn: 160799
|
| |
|
|
| |
llvm-svn: 160798
|
| |
|
|
| |
llvm-svn: 160797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is still a work in progress.
Out-of-order CPUs usually execute instructions from multiple basic
blocks simultaneously, so it is necessary to look at longer traces when
estimating the performance effects of code transformations.
The MachineTraceMetrics analysis will pick a typical trace through a
given basic block and provide performance metrics for the trace. Metrics
will include:
- Instruction count through the trace.
- Issue count per functional unit.
- Critical path length, and per-instruction 'slack'.
These metrics can be used to determine the performance limiting factor
when executing the trace, and how it will be affected by a code
transformation.
Initially, this will be used by the early if-conversion pass.
llvm-svn: 160796
|
| |
|
|
|
|
|
|
|
|
|
|
| |
started from" in ThreadPlanStepOverRange so you don't
artificially reject stepping out of a function you stepped into when stepping through an inlined range.
Also fill in the target in the symbol context we make up for the inlined stepping range in ThreadPlanStepOut.
<rdar://problem/11765912>
llvm-svn: 160794
|
| |
|
|
| |
llvm-svn: 160791
|
| |
|
|
|
|
|
|
|
|
|
|
| |
typeinfo.cpp. Both new.cpp and typeinfo.cpp have code that is conditionally compiled
based on the LIBCXXRT and _LIBCPPABI_VERSION defines, but those files
do not currently include <cxxabi.h> in the non __APPLE__ case. The
attached patch updates those files so that for non __APPLE__ builds
<cxxabi.h> is included if available or if LIBCXXRT is set. I'm
modeling this on the recent updates to exception.cpp.
llvm-svn: 160790
|
| |
|
|
|
|
| |
is missing in method prototype. // rdar://11939584
llvm-svn: 160789
|
| |
|
|
|
|
| |
respect default arguments".
llvm-svn: 160788
|