| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
No functional change is intended.
llvm-svn: 261307
|
|
|
|
| |
llvm-svn: 261306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
especially the *structure* of it with respect to various pass managers.
This uncovers an absolute horror show of problems. This test shows just
how bad PR24804 is: we have a totaly of *seven* loop pass managers in
the main optimization pipeline.
I've tried to comment the various bits to the best of my knowledge, but
more enhancements here would be great.
Also great would be folks adding various test for other pipelines, I'm
focused on trying to fix the O2 pipeline. I just wanted a test to show
what I'm changing.
llvm-svn: 261305
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17178
llvm-svn: 261304
|
|
|
|
|
|
|
|
|
|
| |
Certain optimization passes (like globaldce) can prune function
declaration that SjLjEHPrepare assumed would exit when it'd
runOnFunction.
This fixes PR26669.
llvm-svn: 261303
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more places to prevent gratuitous re-"runs" of these passes.
The passes themselves don't do any work when run, but we keep spending
time scheduling and running these needlessly when we really don't need
to do so.
This is the first patch towards fixing the really horrible loop pass
pipeline fragmentation pointed out by Sanjoy in PR24804.
llvm-svn: 261302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For templates, fields can have incomplete types:
template <class T>
struct A2 {
struct B;
B b;
};
Don't try to touch the DefinitionData of those fields.
llvm-svn: 261301
|
|
|
|
| |
llvm-svn: 261300
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17154
llvm-svn: 261299
|
|
|
|
| |
llvm-svn: 261298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
llvm-svn: 261297
|
|
|
|
| |
llvm-svn: 261296
|
|
|
|
|
|
|
|
|
| |
Created by:
cd www
curl -O http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_index.html
./make_cxx_dr_status
llvm-svn: 261295
|
|
|
|
| |
llvm-svn: 261294
|
|
|
|
|
|
|
|
|
|
| |
Add a checker callback that is called when the analyzer starts analyzing a
function either at the top level or when inlined. This will be used by a
follow-on patch making the DeallocChecker path sensitive.
Differential Revision: http://reviews.llvm.org/D17418
llvm-svn: 261293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parse correctly
Fixes crash referenced in PR25181 where dyn_cast is called on a null
instance of LM.Method.
Reviewers: majnemer, rnk
Patch by Don Hinton
Differential Revision: http://reviews.llvm.org/D17072
llvm-svn: 261292
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17426
llvm-svn: 261291
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangConfig requires LLVMConfig, so add find_package call in
ClangConfig so find_package(clang REQUIRED CONFIG) will just work. This
makes it easier for cmake based projects to use clang, e.g., tools using
ClangTooling.
Patch by Don Hinton
Differential Revision: http://reviews.llvm.org/D13622
llvm-svn: 261290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds 3 tables to html report:
- list of covered files with number of functions covered.
- list of not covered files
- list of not covered functions.
I tried to put most coverage-calculating functionality into
SourceCoverageData.
Differential Revision: http://reviews.llvm.org/D17421
llvm-svn: 261287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without this, this command
$ llvm-run llc -stop-after machine-cp -o - <( echo '' )
outputs an error, because we close stdout twice -- once when closing the
file opened for "-o", and again when closing outs().
Also clarify in the outs() definition that you can't ever call it if you
want to open your own raw_fd_ostream on stdout.
Reviewers: jroelofs, tstellarAMD
Subscribers: jholewinski, qcolombet, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D17422
llvm-svn: 261286
|
|
|
|
| |
llvm-svn: 261285
|
|
|
|
|
|
| |
This test builds on 261250 (IR support for cmpxchg of pointers) and 261245 (capture tracking support for cmpxchg) to show that correctly analyze the capturing of pointers in a cmpxchg of pointer type.
llvm-svn: 261284
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, we do not allow cmpxchg operations with pointer arguments. We require the frontend to insert ptrtoint casts and do the cmpxchg in integers. While correct, this is problematic from a couple of perspectives:
1) It makes the IR harder to analyse (for instance, it make capture tracking overly conservative)
2) It pushes work onto the frontend authors for no real gain
This patch implements the simplest form of IR support. As we did with floating point loads and stores, we teach AtomicExpand to convert back to the old representation. This prevents us needing to change all backends in a single lock step change. Over time, we can migrate each backend to natively selecting the pointer type. In the meantime, we get the advantages of a cleaner IR representation without waiting for the backend changes.
Differential Revision: http://reviews.llvm.org/D17413
llvm-svn: 261281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
|
|
|
|
|
|
|
|
|
| |
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
|
|
|
|
|
|
|
|
|
|
|
| |
-Wcomma will detect and warn on most uses of the builtin comma operator. It
currently whitelists the first and third statements of the for-loop. For other
cases, the warning can be silenced by casting the first operand of the comma
operator to void.
Differential Revision: http://reviews.llvm.org/D3976
llvm-svn: 261278
|
|
|
|
|
|
|
|
|
|
| |
This is effectively NFC because Atom is the only in-order x86 subtarget currently,
but the predicate would have become wrong if any other in-order CPU came along.
See related discussion in:
http://reviews.llvm.org/D16836
llvm-svn: 261275
|
|
|
|
|
|
|
|
| |
class.
Patch by Elisavet Sakellari!
llvm-svn: 261274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
PR26666: CMAKE_BUILD_TYPE was previously being reset to blank.
Reviewers: rnk, beanz
Subscribers: llvm-commits
Patch By: Derek Bruening
Differential Revision: http://reviews.llvm.org/D17398
llvm-svn: 261273
|
|
|
|
|
|
| |
source/Commands/CommandObjectBreakpoint.cpp; other minor fixes.
llvm-svn: 261272
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261271
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261270
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma.
llvm-svn: 261269
|
|
|
|
|
|
|
|
|
| |
Old compilers don't like constexpr, but we're only going to use this in one
place anyway: this file. Everyone else should go through PointerLikeTypeTraits.
Update to r261259.
llvm-svn: 261268
|
|
|
|
|
|
| |
loading the corpus
llvm-svn: 261267
|
|
|
|
|
|
|
|
|
| |
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).
Obviously the pass still only used from PPC at this point. Subsequent
patches will start driving this from ARM64 as well.
Due to the previous patch most lines should show up as moved lines.
llvm-svn: 261265
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done only to make the next patch that move the pass out PPC to
Transforms easier to read. After this most line should show up as moved
lines in that patch.
This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).
llvm-svn: 261264
|
|
|
|
| |
llvm-svn: 261263
|
|
|
|
|
|
|
|
|
|
| |
If we know that all of our successors want to be in the exact same
state, it makes sense to hoist the state transition into their common
predecessor.
Differential Revision: http://reviews.llvm.org/D17391
llvm-svn: 261262
|
|
|
|
| |
llvm-svn: 261261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in TypeLocBuilder::pushImpl wasn't correctly handling the case
where an element that has an 8-byte alignment was being pushed.
I plan to follow up with a patch to remove redundancies and simplify the
function.
rdar://problem/23838912
Differential Revision: http://reviews.llvm.org/D16843
llvm-svn: 261260
|
|
|
|
|
|
| |
...and when you try to store negative values in it.
llvm-svn: 261259
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRBuilder has two ways of putting bundle operands on calls: the default
operand bundle, and an overload of CreateCall that takes an operand
bundle list.
Previously, this overload used a default argument of None. This made it
impossible to distinguish between the case were the caller doesn't care
about bundles, and the case where the caller explicitly wants no
bundles. We behaved as if they wanted the latter behavior rather than
the former, which led to problems with simplifylibcalls and WinEH.
This change fixes it by making the parameter non-optional, so we can
distinguish these two cases.
llvm-svn: 261258
|
|
|
|
| |
llvm-svn: 261255
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API.
Reviewers: echristo, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17359
llvm-svn: 261254
|
|
|
|
| |
llvm-svn: 261253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using Backend_EmitLL attemps to create a file with an empty filename.
This is problematic in certain environments: an empty filename may be
illegal, or the default output path may not be writable (in the case
where an empty filename would otherwise have some non-failing
semantics). This patch switches to use Backend_EmitMCNull, which
allows CodeGen to run, but does not attempt to create or write an
output file.
Differential Revision: http://reviews.llvm.org/D17405
llvm-svn: 261252
|
|
|
|
| |
llvm-svn: 261251
|
|
|
|
| |
llvm-svn: 261250
|