| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This is useful when only analyzing functions.
llvm-svn: 303420
|
| |
|
|
| |
llvm-svn: 303419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per-function predicates.
Summary:
This causes them to be re-computed more often than necessary but resolves
objections that were raised post-commit on r301750.
Reviewers: qcolombet, ab, t.p.northover, rovka, kristof.beyls
Reviewed By: qcolombet
Subscribers: igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D32861
llvm-svn: 303418
|
| |
|
|
|
|
| |
Also s/0/nullptr in the call site in LV.
llvm-svn: 303416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch updates the handling of multiline trailing comment sections in
import statement lines to make it more consistent with the case in general.
This includes updating the parsing logic to collect the trailing comment
sections and the formatting logic to not insert escaped newlines at the end of
comment lines in import statement lines.
Specifically, before this patch this code:
```
#include <a> // line 1
// line 2
```
will be turned into two unwrapped lines, whereas this code:
```
int i; // line 1
// line 2
```
is turned into a single unwrapped line, enabling reflowing across comments.
An example where the old behaviour is bad is when partially formatting the lines
3 to 4 of this code:
```
#include <a> // line 1
// line 2
int i;
```
which gets turned into:
```
#include <a> // line 1
// line 2
int i;
```
because the two comment lines were independent and the indent was copied.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33351
llvm-svn: 303415
|
| |
|
|
|
|
| |
possibly obsolete. [-Wdocumentation]
llvm-svn: 303414
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: qcolombet, ab, t.p.northover, aditya_nandakumar, dsanders
Reviewed By: qcolombet
Subscribers: rovka, kristof.beyls, javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D33317
llvm-svn: 303412
|
| |
|
|
| |
llvm-svn: 303411
|
| |
|
|
| |
llvm-svn: 303410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a squash of ~5 reverts of, well, pretty much everything
I did today. Something is seriously broken with lit on Windows
right now, and as a result assertions that fire in tests are
triggering failures. I've been breaking non-Windows bots all
day which has seriously confused me because all my tests have
been passing, and after running lit with -a to view the output
even on successful runs, I find out that the tool is crashing
and yet lit is still reporting it as a success!
At this point I don't even know where to start, so rather than
leave the tree broken for who knows how long, I will get this
back to green, and then once lit is fixed on Windows, hopefully
hopefully fix the remaining set of problems for real.
llvm-svn: 303409
|
| |
|
|
| |
llvm-svn: 303408
|
| |
|
|
|
|
|
|
|
|
|
| |
We were using a BumpPtrAllocator to allocate stable storage for
a record, then trying to insert that into a hash table. If a
collision occurred, the bytes were never inserted and the
allocation was unnecessary. At the cost of an extra hash
computation, check first if it exists, and only if it does do
we allocate and insert.
llvm-svn: 303407
|
| |
|
|
|
|
|
| |
(or non-store, more in general). Fixes PR33086. Caught by the
store verifier.
llvm-svn: 303406
|
| |
|
|
| |
llvm-svn: 303405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following test case tried to compute the lexicographic minimum of the
following set during alias analysis, which caused very long compile time:
[p_0, p_1, p_2, p_3, p_4, p_5] -> { MemRef0[i0] : (517p_3 >= 70944 - 298p_2 and
256i0 >= -71199 + 298p_2 + 517p_3 and 256i0 <= -70944 + 298p_2 + 517p_3) or
(409p_4 >= 57120 - 298p_2 and 256i0 >= -57375 + 298p_2 + 409p_4 and 256i0 <=
-57120 + 298p_2 + 409p_4) or (104p_4 >= 17329 + 149p_2 - 50p_3 and 128i0 >=
17328 + 149p_2 - 50p_3 - 104p_4 and 128i0 <= 17455 + 149p_2 - 50p_3 - 104p_4) or
(104p_4 <= 17328 + 149p_2 - 50p_3 and 128i0 >= 17201 + 149p_2 - 50p_3 - 104p_4
and 128i0 <= 17328 + 149p_2 - 50p_3 - 104p_4) or (409p_4 <= 57119 - 298p_2 and
256i0 >= -57120 + 298p_2 + 409p_4 and 256i0 <= -56865 + 298p_2 + 409p_4) or
(517p_3 <= 70943 - 298p_2 and 256i0 >= -70944 + 298p_2 + 517p_3 and 256i0 <=
-70689 + 298p_2 + 517p_3) or (p_1 >= 2 + 2p_0 and 298p_5 >= 70944 - 517p_3 and
256i0 >= -71199 + 517p_3 + 298p_5 and 256i0 <= -70944 + 517p_3 + 298p_5) or (p_1
>= 2 + 2p_0 and 298p_5 >= 57120 - 409p_4 and 256i0 >= -57375 + 409p_4 + 298p_5
>and 256i0 <= -57120 + 409p_4 + 298p_5) or (p_1 >= 2 + 2p_0 and 149p_5 <= -17329
>+ 50p_3 + 104p_4 and 128i0 >= 17328 - 50p_3 - 104p_4 + 149p_5 and 128i0 <=
>17455 - 50p_3 - 104p_4 + 149p_5) or (p_1 >= 2 + 2p_0 and 149p_5 >= -17328 +
>50p_3 + 104p_4 and 128i0 >= 17201 - 50p_3 - 104p_4 + 149p_5 and 128i0 <= 17328
>- 50p_3 - 104p_4 + 149p_5) or (p_1 >= 2 + 2p_0 and 298p_5 <= 57119 - 409p_4 and
>256i0 >= -57120 + 409p_4 + 298p_5 and 256i0 <= -56865 + 409p_4 + 298p_5) or
>(p_1 >= 2 + 2p_0 and 298p_5 <= 70943 - 517p_3 and 256i0 >= -70944 + 517p_3 +
>298p_5 and 256i0 <= -70689 + 517p_3 + 298p_5) }
We now guard the potentially expensive functions in Polly's scop analysis to
gracefully bail out in case of overly long compilation times.
llvm-svn: 303404
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similar to my previous fix, it turns out llvm-pdbdump has been
printing an incorrect value since the beginning of time, but
we didn't know it was incorrect. Specifically, we were interpreting
a TypeIndex as referencing a type from the TPI stream when it
actually should come from the IPI stream. So we were printing a
string that looked like a valid string, but was just from the
wrong place.
llvm-svn: 303403
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fixes (NFC)."
This reverts commit r303383.
This breaks the modules-enabled macOS build with:
lib/Support/LockFileManager.cpp:86:7: error: declaration of 'gethostuuid' must be imported from module 'Darwin.POSIX.unistd' before it is required
llvm-svn: 303402
|
| |
|
|
|
|
|
|
| |
syntax unless we have a reason to think otherwise.
This improves error recovery in a couple of cases.
llvm-svn: 303398
|
| |
|
|
|
|
|
|
|
|
|
| |
Apparently this was always broken, but previously we were more
graceful about it and we would print "unknown udt" if we couldn't
find the type index, whereas now we just segfault because we
assume it's valid. But this exposed a real bug, which is that
we weren't looking in the right place. So fix that, and also
fix this crash at the same time.
llvm-svn: 303397
|
| |
|
|
|
|
|
|
|
|
| |
pruneSubRegValues() needs to remove subregister ranges starting at
instructions that later get removed by eraseInstrs(). It missed to check
one case in which eraseInstrs() would remove an instruction.
Fixes http://llvm.org/PR32688
llvm-svn: 303396
|
| |
|
|
| |
llvm-svn: 303395
|
| |
|
|
| |
llvm-svn: 303394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We can have cycles between PHIs and this causes singleReachablePhi()
to call itself indefintely (until we run out of stack). The proper
solution would be that of computing SCCs, but it's not worth for
now, so just keep a visited set and give up when we find a cycle.
Thanks to Dan for the discussion/help with this.
Fixes PR33014.
llvm-svn: 303393
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D33158
llvm-svn: 303392
|
| |
|
|
| |
llvm-svn: 303391
|
| |
|
|
|
|
|
| |
This map will be needed to rewrite symbol streams after re-writing
the corresponding type streams.
llvm-svn: 303390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merging PDBs is a feature that will be used heavily by
the linker. The functionality already exists but does not
have deep test coverage because it's not easily exposed through
any tools. This patch aims to address that by adding the
ability to merge PDBs via llvm-pdbdump. It takes arbitrarily
many PDBs and outputs a single PDB.
Using this new functionality, a test is added for merging
type records. Future patches will add the ability to merge
symbol records, module information, etc.
llvm-svn: 303389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we have multiple notions of things that represent collections of
types. Most commonly used are TypeDatabase, which is supposed to keep
mappings from TypeIndex to type name when reading a type stream, which
happens when reading PDBs. And also TypeTableBuilder, which is used to
build up a collection of types dynamically which we will later serialize
(i.e. when writing PDBs).
But often you just want to do some operation on a collection of types, and
you may want to do the same operation on any kind of collection. For
example, you might want to merge two TypeTableBuilders or you might want
to merge two type streams that you loaded from various files.
This dichotomy between reading and writing is responsible for a lot of the
existing code duplication and overlapping responsibilities in the existing
CodeView library classes. For example, after building up a
TypeTableBuilder with a bunch of type records, if we want to dump it we
have to re-invent a bunch of extra glue because our dumper takes a
TypeDatabase or a CVTypeArray, which are both incompatible with
TypeTableBuilder.
This patch introduces an abstract base class called TypeCollection which
is shared between the various type collection like things. Wherever we
previously stored a TypeDatabase& in some common class, we now store a
TypeCollection&.
The advantage of this is that all the details of how the collection are
implemented, such as lazy deserialization of partial type streams, is
completely transparent and you can just treat any collection of types the
same regardless of where it came from.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303388
|
| |
|
|
| |
llvm-svn: 303387
|
| |
|
|
|
|
|
|
|
|
|
| |
In r302231 we mistakenly use bitwise or (|) instead of logical
or (||). This patch fixes that.
Contributed-by: Sameer AbuAsal <sabuasal@codeaurora.org>
Differential Revision: https://reviews.llvm.org/D33337
llvm-svn: 303386
|
| |
|
|
|
|
|
| |
This time with an additional fix, i.e. we remove the dead
@llvm.ssa.copy instruction.
llvm-svn: 303385
|
| |
|
|
|
|
|
|
|
|
| |
This converts the last (chronologically) user of OutputSections to use
the linker script commands instead.
The idea is to convert all uses after fabricateDefaultCommands, so
that we have a single representation.
llvm-svn: 303384
|
| |
|
|
| |
llvm-svn: 303383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The syntax is actually `for await (const x of y)` (d'oh).
This also fixes a crash for `for` tokens not followed by additional tokens.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33329
llvm-svn: 303382
|
| |
|
|
|
|
|
|
|
|
|
| |
Also, fix the old-style capitalization of the related functions
and move them to the 'private' section of the class since they
are just helpers of the visit* functions.
As shown in the post-commit comments for D32143, we are missing
folds for xor-of-icmps.
llvm-svn: 303381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After discussing the current defaults with a couple of parties, the consensus
is that they are too high. 1Mb of quarantine has about a 4Mb impact on PSS, so
memory usage goes up quickly.
This is obviously configurable, but the default value should be more
"approachable", so both the global size and the thread local size are 1/4 of
what they used to be.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33321
llvm-svn: 303380
|
| |
|
|
|
|
|
|
| |
Currently m_Not only works the canonical xor X, -1 form that InstCombine produces. InstSimplify can't rely on this canonicalization.
Differential Revision: https://reviews.llvm.org/D33331
llvm-svn: 303379
|
| |
|
|
|
|
|
|
|
| |
Our output is not compatible with the Binding feature, so make it
explicit that.
Differential Revision: https://reviews.llvm.org/D33336
llvm-svn: 303378
|
| |
|
|
|
|
| |
This reverts commit r303375 since it didn't compile.
llvm-svn: 303377
|
| |
|
|
|
|
|
| |
This test doesn't rely on the order of asynchronous messages, enable
threads so we have at least some coverage for those code paths.
llvm-svn: 303376
|
| |
|
|
| |
llvm-svn: 303375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, LLD-produced executables had IAT (Import Address Table) and
ILT (Import Lookup Table) as separate chunks of data, although their
contents are identical. My interpretation of the COFF spec when I wrote
the COFF linker is that they need to be separate tables even though they
are the same.
But Peter found that the Windows loader is fine with executables in
which IAT and ILT are merged. This is a patch to merge IAT and ILT.
I confirmed that an lld-link self-hosted with this patch works fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33064
Differential Revision: https://reviews.llvm.org/D33326
llvm-svn: 303374
|
| |
|
|
|
|
|
|
|
|
| |
specification and the TU to the new module.
This is necessary to get the module ownership correct for entities that we
temporarily hang off the TranslationUnitDecl, such as template parameters and
function parameters.
llvm-svn: 303373
|
| |
|
|
|
|
|
|
|
|
| |
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
|
| |
|
|
|
|
|
|
|
| |
The import lists are already binned by DLL name, so there's no need to
deduplicate here.
Differential Revision: https://reviews.llvm.org/D33330
llvm-svn: 303371
|
| |
|
|
|
|
|
|
|
|
|
| |
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
|
| |
|
|
|
|
|
|
|
| |
This also reverts follow-ups r303292 and r303298.
It broke some Chromium tests under MSan, and apparently also internal
tests at Google.
llvm-svn: 303369
|
| |
|
|
| |
llvm-svn: 303368
|
| |
|
|
| |
llvm-svn: 303367
|
| |
|
|
|
|
|
|
|
|
| |
looking up a dependent name in a record that derives from itself
rdar://32273000
Differential Revision: https://reviews.llvm.org/D33324
llvm-svn: 303366
|