| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
manager to avoid a slow linear scan of every immutable pass and on every
attempt to find an analysis pass.
This speeds up 'check-llvm' on an unoptimized build for me by 15%, YMMV.
It should also help (a tiny bit) other folks that are really
bottlenecked on repeated runs of tiny pass pipelines across small IR
files.
llvm-svn: 247240
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11858
llvm-svn: 247239
|
| |
|
|
|
|
|
|
|
|
| |
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
llvm-svn: 247238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes in this patch are as follows:
1. Modify the emitPrologue and emitEpilogue methods to work properly when the prologue and epilogue blocks are not the first/last blocks in the function
2. Fix a bug in PPCEarlyReturn optimization caused by an empty entry block in the function
3. Override the runShrinkWrap PredicateFtor (defined in TargetMachine) to check whether shrink wrapping should run:
Shrink wrapping will run on PPC64 (Little Endian and Big Endian) unless -enable-shrink-wrap=false is specified on command line
A new test case, ppc-shrink-wrapping.ll was created based on the existing shrink wrapping tests for x86, arm, and arm64.
Phabricator review: http://reviews.llvm.org/D11817
llvm-svn: 247237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we need to teach isFrameOffsetLegal about STNP.
It already knew about the STP/LDP variants, but those were probably
never exercised, because it's only the load/store optimizer that
generates STP/LDP, and the only user of the method is frame lowering,
which runs earlier.
The STP/LDP cases were wrong: they didn't take into account the fact
that they return two results, not one, so the immediate offset will be
the 4th operand, not the 3rd.
Follow-up to r247234.
llvm-svn: 247236
|
| |
|
|
|
|
|
|
|
| |
This sort-of deprecates macho-dump. It may take still a little while
to garbage collect it, but at least there's no real usage of it in
the tree anymore. New tests should always rely on llvm-readobj or
llvm-objdump.
llvm-svn: 247235
|
| |
|
|
|
|
| |
Followup to r247231.
llvm-svn: 247234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapply a variant commit r247179 after post-commit review from
D.Blaikie.
Hopefully I got it right this time: lifetime of initializer list ends
as with any expression, which make invalid the pattern:
ArrayRef<int> Arr = { 1, 2, 3, 4};
Just like StringRef, ArrayRef shouldn't be used to initialize local
variable but only as function argument.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247233
|
| |
|
|
|
|
|
|
| |
After r247186, a vector is no longer needed as the push_front for
the code is removed.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247232
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We could go through the load/store optimizer and match STNP where
we would have matched a nontemporal-annotated STP, but that's not
reliable enough, as an opportunistic optimization.
Insetad, we can guarantee emitting STNP, by matching them at ISel.
Since there are no single-input nontemporal stores, we have to
resort to some high-bits-extracting trickery to generate an STNP
from a plain store.
Also, we need to support another, LDP/STP-specific addressing mode,
base + signed scaled 7-bit immediate offset.
For now, only match the base. Let's make it smart separately.
Part of PR24086.
llvm-svn: 247231
|
| |
|
|
| |
llvm-svn: 247230
|
| |
|
|
|
|
|
| |
This will be caught by existing tests with a
verifier check to be added in a future commit.
llvm-svn: 247229
|
| |
|
|
|
|
| |
rdar://22071955
llvm-svn: 247228
|
| |
|
|
| |
llvm-svn: 247227
|
| |
|
|
|
|
|
| |
This caused build breakges, e.g.
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/24926
llvm-svn: 247226
|
| |
|
|
|
|
| |
To be used by other targets.
llvm-svn: 247225
|
| |
|
|
|
|
| |
a text file that contains all .a filenames and use that when linking in Xcode.
llvm-svn: 247224
|
| |
|
|
| |
llvm-svn: 247223
|
| |
|
|
|
|
|
|
|
|
|
| |
Seems it broke the Polly build.
From http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/11687/steps/compile/logs/stdio:
In file included from /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/lib/TableGen/Record.cpp:14:0:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:369:3: error: looser throw specifier for 'virtual llvm::TypedInit::~TypedInit()'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:270:11: error: overriding 'virtual llvm::Init::~Init() noexcept (true)'
llvm-svn: 247222
|
| |
|
|
|
|
| |
The assertion was weaker than it should be and gave the impression we're growing the number of base defining values being considered during the fixed point interation. That's not true. The tighter form of the assert is useful documentation.
llvm-svn: 247221
|
| |
|
|
| |
llvm-svn: 247220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the complexity is in cleanupret, and it mostly follows the same
codepaths as catchret, except it doesn't take a return value in RAX.
This small example now compiles and executes successfully on win32:
extern "C" int printf(const char *, ...) noexcept;
struct Dtor {
~Dtor() { printf("~Dtor\n"); }
};
void has_cleanup() {
Dtor o;
throw 42;
}
int main() {
try {
has_cleanup();
} catch (int) {
printf("caught it\n");
}
}
Don't try to put the cleanup in the same function as the catch, or Bad
Things will happen.
llvm-svn: 247219
|
| |
|
|
|
|
|
|
| |
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D12741
llvm-svn: 247218
|
| |
|
|
| |
llvm-svn: 247217
|
| |
|
|
|
|
|
|
| |
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D12740
llvm-svn: 247216
|
| |
|
|
|
|
|
|
| |
This reapply commit r247178 after post-commit review from D.Blaikie
in a way that makes it compatible with the existing API.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose is to allow templated wrapper to work with either
ArrayRef or any convertible operation:
template<typename Container>
void wrapper(const Container &Arr) {
impl(makeArrayRef(Arr));
}
with Container being a std::vector, a SmallVector, or an ArrayRef.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247214
|
| |
|
|
| |
llvm-svn: 247213
|
| |
|
|
|
|
| |
Factor out common code related to naming values, fix a small style issue. More to follow in separate changes.
llvm-svn: 247211
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change is simply enhancing the existing inference algorithm to handle insertelement instructions by conservatively inserting a new instruction to propagate the vector of associated base pointers. In the process, I'm ripping out the peephole optimizations which mostly helped cover the fact this hadn't been done.
Note that most of the newly inserted nodes will be nearly immediately removed by the post insertion optimization pass introduced in 246718. Arguably, we should be trying harder to avoid the malloc traffic here, but I'd rather get the code correct, then worry about compile time.
Unlike previous extensions of the algorithm to handle more case, I discovered the existing code was causing miscompiles in some cases. In particular, we had an implicit assumption that the peephole covered *all* insert element instructions, so if we had a value directly based on a insert element the peephole didn't cover, we proceeded as if it were a base anyways. Not good. I believe we had the same issue with shufflevector which is why I adjusted the predicate for them as well.
Differential Revision: http://reviews.llvm.org/D12583
llvm-svn: 247210
|
| |
|
|
|
|
|
|
| |
receiver extension for message sends via property syntax.
rdar://22172983
llvm-svn: 247209
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the base pointer algorithm wasn't deterministic. The core fixed point was (of course), but we were inserting new nodes and optimizing them in an order which was unspecified and variable. We'd somewhat hacked around this for testing by sorting by value name, but that doesn't solve the general determinism problem.
Instead, we can use the order of traversal over the def/use graph to give us a single consistent ordering. Today, this is a DFS order, but the exact order doesn't mater provided it's deterministic for a given input.
(Q: It is safe to rely on a deterministic order of operands right?)
Note that this only fixes the determinism within a single inference step. The inference step is currently invoked many times in a non-deterministic order. That's a future change in the sequence. :)
Differential Revision: http://reviews.llvm.org/D12640
llvm-svn: 247208
|
| |
|
|
|
|
| |
rdar://22464808
llvm-svn: 247207
|
| |
|
|
| |
llvm-svn: 247206
|
| |
|
|
|
|
| |
With this simple static programs run again.
llvm-svn: 247205
|
| |
|
|
| |
llvm-svn: 247204
|
| |
|
|
| |
llvm-svn: 247203
|
| |
|
|
|
|
| |
and clang .a files. We now just make a file list which we pass to the linker.
llvm-svn: 247202
|
| |
|
|
|
|
|
|
| |
Visit disjoint sets in a deterministic order based on the maximum BitSetNM
index, otherwise the order in which we visit them will depend on pointer
comparisons. This was being exposed by MSan.
llvm-svn: 247201
|
| |
|
|
|
|
|
|
| |
notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB
This is NFC, other than a code re-org
llvm-svn: 247200
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).
http://reviews.llvm.org/D11859
llvm-svn: 247199
|
| |
|
|
| |
llvm-svn: 247198
|
| |
|
|
| |
llvm-svn: 247197
|
| |
|
|
|
|
|
|
| |
"clang::ASTContext *" and a "void *", we need to know if anyone is trying to create a CompilerType from a clang::ASTContext that has no backing ClangASTContext.
This assert will fire if this is the case and we will need to fix the offending code.
llvm-svn: 247196
|
| |
|
|
|
|
|
|
| |
I was experimenting with it briefly, and then settled on Target::GetTypeSystem + TypeSystem::GetBasicType, so this API is not necessary to have
Thanks to Ryan Brown for bringing it to my attention
llvm-svn: 247195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration
Summary: Diagnose variable and function concept declarations when an invalid specifier appears
Reviewers: rsmith, aaron.ballman, faisalv, fraggamuffin, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12435
llvm-svn: 247194
|
| |
|
|
| |
llvm-svn: 247193
|
| |
|
|
|
|
|
|
|
|
|
| |
The 32-bit tables don't actually contain PC range data, so emitting them
is incredibly simple.
The 64-bit tables, on the other hand, use the same table for state
numbering as well as label ranges. This makes things more difficult, so
it will be implemented later.
llvm-svn: 247192
|
| |
|
|
|
|
|
|
|
|
| |
It often hangs or times out, and obscures issues with other tests.
Just skip it for now (until the FreeBSD test suite is producing
consistent results) so that we can get a buildbot back.
Previous investigation (for failures) in llvm.org/pr18522
llvm-svn: 247190
|
| |
|
|
|
|
| |
formatting special characters
llvm-svn: 247189
|