COFF: Fix single StringRef return error

This should appease the lld build bot regression
Intrroduced by rL303490

llvm-svn: 303493

Fix PR25627: constant expressions being odr-used in template arguments.

This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)

Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used).  By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.

For e.g:
  template<int> struct X { };
  void f() {
    const int N = 10;
    X<N> x; // should be OK.
    [] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
  }

See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627

In summary (and reiteration), the fix is as follows:

    - Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
    - Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.

See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.

Thanks Richard!

llvm-svn: 303492

COFF: migrate def parser from LLD to LLVM [2/2]

This is split up into two commits.
This commit removes the DEF parser from LLD
See the previous commit for the creation in LLVM.

Reviewers: ruiu

Differential Revision: https://reviews.llvm.org/D32689

llvm-svn: 303491

COFF: migrate def parser from LLD to LLVM [1/2]

This is split up into two commits.
The will create the DEF parser in LLVM.
Check the following commit to see the removal from LLD

Reviewers: ruiu

Differential Revision: https://reviews.llvm.org/D32689

llvm-svn: 303490

Fix test typo. NFC

llvm-svn: 303489

[Devirtualization] insert placement new barrier with -O0

Summary:
To not break LTO with different optimizations levels, we should insert
the barrier regardles of optimization level.

Reviewers: rjmccall, rsmith, mehdi_amini

Reviewed By: mehdi_amini

Subscribers: mehdi_amini, cfe-commits

Differential Revision: https://reviews.llvm.org/D32401

llvm-svn: 303488

Docs: Fix pluralization in CMake docs

Fixed "most platform" to read "most platforms", and changed "are not
using the same" to "use different" as a drive-by.

llvm-svn: 303487

[docs] Small style nits.

llvm-svn: 303486

Fix buildbots after r303429

A test case with a GPU runline was added without setting 'REQUIRES=pollyacc'. We
drop the GPU run line, as the basic functionality can already be tested with
the normal code generation.

llvm-svn: 303485

[index] Fix forward declarations interfering with USR generation of external source symbols

Patch by Nathan Hawes.
https://reviews.llvm.org/D33346

llvm-svn: 303484

Fix -Wunneeded-internal-declaration by removing constant arrays only used in sizeof expressions, in favor of constants containing the size directly

llvm-svn: 303483

llvm-symbolizer: Support multiple CUs in a single DWO file

llvm-svn: 303482

Revert "[compiler-rt] Change default of allow_user_segv_handler to true"

Failed libFuzzer tests on Windows.

This reverts commit r303476.

llvm-svn: 303481

Add functionality to cvtres to parse all entries in res file.

Summary: Added the new modules in the Object/ folder.  Updated the
llvm-cvtres interface as well, and added additional tests.

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D33180

llvm-svn: 303480

Rename RAII objects for performing eager instantiation to have names that
describe what they're for, not how they do it, and factor out a bit more
common code into them.

llvm-svn: 303479

CodeGenModule: Always output wchar_size, check LLVM assumptions.

Re-commit r303463 now that LLVM is fixed and adjust some lit tests.

llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.

Differential Revision: https://reviews.llvm.org/D32982

llvm-svn: 303478

Fix breakage after r303461

- Improve wchar_t size predicitions based on target triple.
- Be less strict in wchar_t size verifier.

llvm-svn: 303477

[compiler-rt] Change default of allow_user_segv_handler to true

Reviewers: eugenis

Subscribers: srhines, kubamracek, llvm-commits

Differential Revision: https://reviews.llvm.org/D32443

llvm-svn: 303476

[NewGVN] Create a StoreExpression instead of a VariableExpression.

In the case where we have an operand defined by a lod of the
same memory location. Historically this was a VariableExpression
because we wanted to make sure they ended up in the same class,
but if we create the right expression, they end up in the same
class anyway.

Fixes PR32897. Thanks to Dan for the detailed discussion and the
fix suggestion.

llvm-svn: 303475

Revert "CodeGenModule: Always output wchar_size, check LLVM assumptions."

Let's revert this for now (and with it the assert()) to get the bots
back to green until I have LLVM synced up properly.

This reverts commit r303463.

llvm-svn: 303474

[NewGVN] Get rid of an assertion.

This was here because we don't want to switch leaders too much,
in order to avoid fixpoint(ing) issue, but it's not sure if it
matters in practice.

A first step towards fixing PR32897.

llvm-svn: 303473

Fix valid-for-expr ellipses eaten as invalid decl

Summary:
The trial parse for declarative syntax accepts an invalid pack
declaration syntax, which is ambiguous with valid pack expansions of
expressions. This commit removes the invalid pack declaration syntax to
avoid mistaking valid pack expansions as invalid declarator components.

Additionally, the trial parse of a //template-argument-list// then needs
to handle the optional ellipsis that is part of that grammar, as opposed
to relying on the trial parse for declarators accepting stray ellipses.

Reviewers: rsmith, rcraik, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33339

llvm-svn: 303472

Cosmetic. Added braces to address gcc warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else].

llvm-svn: 303471

Revert "Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator.""

This reapplies commit r303438 modified to not verify cross-imported
bitcode in FunctionImporter.

rdar://problem/31233625

Differential Revision: https://reviews.llvm.org/D33370

llvm-svn: 303470

Remove last (unnecessary) use of mapping from SourceLocation to Module and
remove the mechanism for doing so.

This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).

llvm-svn: 303469

[modules] Simplify module macro handling in non-local-submodule-visibility mode.

When reaching the end of a module, we used to convert its macros to
ModuleMacros but also leave them in the MacroDirective chain for the
identifier. This meant that every lookup of such a macro would find two
(identical) definitions. It also made it difficult to determine the correct
owner for a macro when reaching the end of a module: the most recent
MacroDirective in the chain could be from an #included submodule rather than
the current module.

Simplify this: whenever we convert a MacroDirective to a ModuleMacro when
leaving a module, clear out the MacroDirective chain for that identifier, and
just rely on the ModuleMacro to provide the macro definition information.

(We don't want to do this for local submodule visibility mode, because in that
mode we maintain a distinct MacroDirective chain for each submodule, and we
need to keep around the prior MacroDirective in case we re-enter the submodule
-- for instance, if its header is #included more than once in a module build,
we need the include guard directive to stick around. But the problem doesn't
arise in this case for the same reason: each submodule has its own
MacroDirective chain, so the macros don't leak out of submodules in the first
place.)

This reinstates r302932, reverted in r302947, with a fix for a bug that
resulted in us sometimes losing macro definitions due to failing to clear out
the overridden module macro list when promoting a directive to a module macro.

llvm-svn: 303468

Revert "ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator."

This reverts commit r303438 while deliberating buildbot breakage.

llvm-svn: 303467

[test] Add support for Objective-C++ tests

Differential revision: https://reviews.llvm.org/D33049

llvm-svn: 303466

Don't override the SDKs and force the use of /System/Library/Frameworks to
find the python headers when buiding crashinfo.c
<rdar://problem/32288076>

llvm-svn: 303465

[compiler-rt] Switch handle_<signal> flags from bool to enum.

Summary: We are going to make it tri-state and remove allow_user_segv_handler.

Reviewers: eugenis, alekseys, kcc

Subscribers: kubamracek, dberris, llvm-commits

Differential Revision: https://reviews.llvm.org/D33159

llvm-svn: 303464

CodeGenModule: Always output wchar_size, check LLVM assumptions.

llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.

Differential Revision: https://reviews.llvm.org/D32982

llvm-svn: 303463

[compiler-rt] Add negative test for boolean flags.

Reviewers: eugenis, alekseyshl

Subscribers: kubamracek, dberris, llvm-commits

Differential Revision: https://reviews.llvm.org/D33344

llvm-svn: 303462

SimplifyLibCalls: Optimize wcslen

Refactor the strlen optimization code to work for both strlen and wcslen.

This especially helps with programs in the wild where people pass
L"string"s to const std::wstring& function parameters and the wstring
constructor gets inlined.

This also fixes a lingerind API problem/bug in getConstantStringInfo()
where zeroinitializers would always give you an empty string (without a
length) back regardless of the actual length of the initializer which
did not work well in the TrimAtNul==false causing the PR mentioned
below.

Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG
memcpy lowering and may lead to some cases for out-of-bounds
zeroinitializer accesses not getting optimized anymore. So some code
with UB may produce out of bound memory reads now instead of just
producing zeros.

The refactoring "accidentally" fixes http://llvm.org/PR32124

Differential Revision: https://reviews.llvm.org/D32839

llvm-svn: 303461

Verifier: Check wchar_size module flag.

Differential Revision: https://reviews.llvm.org/D32974

llvm-svn: 303460

[ODRHash] Revert r303450 to fix buildbot

r303450
[ODRHash] Support TemplateName and TemplateArgument

llvm-svn: 303459

Fix off-by-one bug in AttributeList::addAttributes index handling

getParamAlignment expects an argument number, not an AttributeList
index.

Johan Englan, who works on LDC, found this bug and told me about it off
list.

llvm-svn: 303458

Added LLVM_FALLTHROUGH to address gcc warning: this statement may fall through.

llvm-svn: 303457

[safestack] Disable stack coloring by default.

Workaround for apparent miscompilation of PR32143.

llvm-svn: 303456

Added missing break.

llvm-svn: 303454

NewGVN: Fix PR32838.
This is a complicated bug involving two issues:
1. What do we do with phi nodes when we prove all arguments are not
live?
2. When is it safe to use value leaders to determine if we can ignore
an argumnet?

llvm-svn: 303453

NewGVN: Print out the StoredValue of a StoreExpression

llvm-svn: 303452

Do not issue -Wnullability-completeness for dependent types that are not written as pointer types.

llvm-svn: 303451

[ODRHash] Support TemplateName and TemplateArgument

llvm-svn: 303450

Fix line-endings.

llvm-svn: 303448

[InstCombine] *Actually* commit the test showing the miscompile.

Clarify a comment while I'm here.

llvm-svn: 303447

Resubmit "[CodeView] Provide a common interface for type collections."

This was originally reverted because it was a breaking a bunch
of bots and the breakage was not surfacing on Windows.  After much
head-scratching this was ultimately traced back to a bug in the
lit test runner related to its pipe handling.  Now that the bug
in lit is fixed, Windows correctly reports these test failures,
and as such I have finally (hopefully) fixed all of them in this
patch.

llvm-svn: 303446

[InstCombine] Add tests to demonstrate the miscompile in PR33078.

llvm-svn: 303445

Last of the major pieces to NewGVN - yay!

Summary:
NewGVN: Handle equivalence between phi of ops and op of phis.

This makes our GVN mostly-complete. It would be complete, modulo some
deliberate choices we make.  This means it detects roughly all herband
equivalences in polynomial time, including cases notoriously hard for
other GVN's to detect.  It also detects a very large swath of the
cases we currently rely on instcombine to detect that involve folding
upwards through phis.

Fixes PR 31125, 31463, PR 31868

Reviewers: davide

Subscribers: Prazek, llvm-commits

Differential Revision: https://reviews.llvm.org/D32151

llvm-svn: 303444

NewGVN: Get rid of most dominating leader check

llvm-svn: 303443

BasicAA: Uninserted instructions have no parent, and notDifferentParent explicitly allows for this case, but getParent crashes when handed one.

llvm-svn: 303442

[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X)

Summary:
While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation.

As per discussion in D32756 .

Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D32916

llvm-svn: 303441

[lit] Take the last error when executing pipelines.

This seems to have been present since the beginning of time,
which is quite surprising.  The symptom was this: Suppose you
have a test with a run line that looks like this:

  RUN: foo | FileCheck %s

foo prints some output and then due to a bug in the program it
asserts.  On Windows this results in the program returning a
negative exit code.  But if enough output had been printed
already by the tool so that the FileCheck match would succeed
then FileCheck would return 0, and because of bad logic in
lit this 0 return value would overwrite the failed return
value from previous items in the pipeline.  This only happened
with negative exit codes.

The most sensible behavior is to just take whatever the first
exit code is.  There is no logical ordering defined on exit
codes, so comparing with < and > does not make a lot of sense.
Instead, as soon as we find the first non-successful return
value, that should be the result of the entire expression.

This fixes the issue, as now tests which fail on non-Windows
platforms also fail for me on Windows as well.

llvm-svn: 303440

[NFC][loopIdiom] Clang format change rL303434

llvm-svn: 303439

ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator.

rdar://problem/31233625

Differential Revision: https://reviews.llvm.org/D33151

llvm-svn: 303438

Rewrite llvm-lto's codegen() using ThinCodeGenerator::run(). NFC-ish.

Differential Revision: https://reviews.llvm.org/D33360

llvm-svn: 303437

Fix typo in test

llvm-svn: 303436

[X86][FMA] Tests showing missed fmsubadd opportunities (PR30633)

llvm-svn: 303435

[LoopIdiom] Refactor return value of isLegalStore [NFC]

Summary:

This NFC simply refactors the return value of LoopIdiomRecognize::isLegalStore() from bool to an enumeration, and
removes the return-through-parameter mechanism that the function was using. This function is constructed such that it will
only ever recognize a single store idiom (memset, memset_pattern, or memcpy), and never a combination of these. As such it
makes much more sense for the return value to be the single idiom that the store matches, rather than
having a separate argument-return for each idiom -- it's cleaner, and makes it clearer that
only a single idiom can be matched.

Patch by Daniel Neilson!

Reviewers: anna, sanjoy, davide, haicheng

Reviewed By: anna, haicheng

Subscribers: haicheng, mzolotukhin, llvm-commits

Differential Revision: https://reviews.llvm.org/D33359

llvm-svn: 303434

[InstSimplify] Fix 80 column violation. NFC

llvm-svn: 303433

[modules] Further delay calling DeclMustBeEmitted until it's safe.

As discussed in D30793, we have some unsafe calls to isConsumerInterestedIn().
This patch implements Richard's suggestion (from the inline comment) that we
should track if we just deserialized an declaration. If we just deserialized,
we can skip the unsafe call because we know it's interesting. If we didn't just
deserialize the declaration, calling isConsumerInterestedIn() should be safe.

We tried to create a test case for this but we were not successful.

Patch by Raphael Isemann (D32499)!

llvm-svn: 303432

[APInt] Add support for dividing or remainder by a uint64_t or int64_t.

Summary:
This patch adds udiv/sdiv/urem/srem/udivrem/sdivrem methods that can divide by a uint64_t. This makes division consistent with all the other arithmetic operations.

This modifies the interface of the divide helper method to work on raw arrays instead of APInts. This way we can pass the uint64_t in for the RHS without wrapping it in an APInt. This required moving all the Quotient and Remainder allocation handling up to the callers. For udiv/urem this was as simple as just creating the Quotient/Remainder with the right size when they were declared. For udivrem we have to rely on reallocate not changing the contents of the variable LHS or RHS is aliased with the Quotient or Remainder APInts. We also have to zero the upper bits of Remainder and Quotient that divide doesn't write to if lhsWords/rhsWords is smaller than the width.

I've update the toString method to use the new udivrem.

Reviewers: hans, dblaikie, RKSimon

Reviewed By: RKSimon

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D33310

llvm-svn: 303431

[Fortran Support] Materialize outermost dimension for Fortran array.

- We use the outermost dimension of arrays since we need this
information to generate GPU transfers.

- In general, if we do not know the outermost dimension of the array
(because the indexing expression is non-affine, for example) then we
simply cannot generate transfer code.

- However, for Fortran arrays, we can use the Fortran array
representation which stores the dimensions of all arrays.

- This patch uses the Fortran array representation to generate code that
computes the outermost dimension size.

Differential Revision: https://reviews.llvm.org/D32967

llvm-svn: 303429

[AMDGPU][MC] Corrected disassembler to decode instructions with 2 literals

See bug 32922: https://bugs.llvm.org//show_bug.cgi?id=32922

Reviewers: artem.tamazov, vpykhtin

Differential Revision: https://reviews.llvm.org/D32912

llvm-svn: 303428

[LoopPredication] NFC. Extract LoopICmp struct and parseLoopICmp helper

llvm-svn: 303427

[LoopPredication] NFC. Extract LoopPredication::expandCheck helper

llvm-svn: 303426

[LoopPredication] NFC. Extract CanExpand helper lambda

llvm-svn: 303425

[LoopPredication] NFC. Add an early exit if there is no guards in the loop

llvm-svn: 303424

[AMDGPU][MC] Fixed bugs in export instruction

See Bugs 33019, 33056:
  https://bugs.llvm.org//show_bug.cgi?id=33019
  https://bugs.llvm.org//show_bug.cgi?id=33056

Reviewers: artem.tamazov, vpykhtin

Differential Revision: https://reviews.llvm.org/D33288

llvm-svn: 303423

Use write instead of read permissions to check for global sections on mac

Summary:
The LINKEDIT section is very large and is read-only. Scanning this
section caused LSan on darwin to be very slow. When only writable sections
are scanned for global pointers, performance improved by a factor of about 25x.

Reviewers: alekseyshl, kubamracek

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D33322

llvm-svn: 303422

[X86][AVX512] Make i1 illegal in the CodeGen

This patch defines the i1 type as illegal in the X86 backend for AVX512.
For DAG operations on <N x i1> types (build vector, extract vector element, ...) i8 is used, and should be truncated/extended.
This should produce better scalar code for i1 types since GPRs will be used instead of mask registers.

Differential Revision: https://reviews.llvm.org/D32273

llvm-svn: 303421

[ScopDetection] Allow detection of full functions

This is useful when only analyzing functions.

llvm-svn: 303420

Restore and update documentation comment for EmitPointerWithAlignment

llvm-svn: 303419

[globalisel][tablegen] Demote OptForSize/OptForMinSize/ForCodeSize to 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

Fix vector pass-through value being unused in IRBuilder::CreateMaskedGather

Also s/0/nullptr in the call site in LV.

llvm-svn: 303416

[clang-format] Handle trailing comment sections in import statement lines

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

CodeGenFunction::EmitPointerWithAlignment(): Prune a \param in r303358, possibly obsolete. [-Wdocumentation]

llvm-svn: 303414

[GlobalISel] IRTranslator: Translate ConstantStruct

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

[APInt] Use b.negate() in place of b = -std::move(b). NFCI

llvm-svn: 303411

Fix compilation failure.

llvm-svn: 303410

Revert "[CodeView] Provide a common interface for type collections."

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

Don't crash if someone tries to visit an empty type stream.

llvm-svn: 303408

[CodeView] Reduce memory usage in TypeSerializer.

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

[NewGVN] Delete the old store when we find congruent to a load.

(or non-store, more in general). Fixes PR33086. Caught by the
store verifier.

llvm-svn: 303406

[ScopInfo] Fix typo in documentation

llvm-svn: 303405

[ScopInfo] Gracefully handle long compile times

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

Fix a broken test.

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

Revert "[ADT] Fix some Clang-tidy modernize-use-using warnings; other minor 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

When a type-id is unexpectedly given a name, assume that the name is unrelated
syntax unless we have a reason to think otherwise.

This improves error recovery in a couple of cases.

llvm-svn: 303398

Fix crasher in CodeView test.

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

LiveIntervalAnalysis: Fix missing case in pruneSubRegValues()

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

Fix typo

llvm-svn: 303395

Fix another warning.

llvm-svn: 303394

[NewGVN] Break infinite recursion in singleReachablePHIPath().

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

[compiler-rt] Replace ifs with switch statement in IsHandledDeadlySignal

Reviewers: eugenis

Subscribers: kubamracek, llvm-commits, dberris

Differential Revision: https://reviews.llvm.org/D33158

llvm-svn: 303392

Fix some build errors and warnings.

llvm-svn: 303391

[CodeView] Raise the source to ID map out of the TypeStreamMerger.

This map will be needed to rewrite symbol streams after re-writing
the corresponding type streams.

llvm-svn: 303390

[llvm-pdbdump] Add the ability to merge PDBs.

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

[CodeView] Provide a common interface for type collections.

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

[InstCombine] add more tests for xor-of-icmps; NFC

llvm-svn: 303387

[ScopInfo] Fix r302231 to use logical or (||). NFC.

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