llvm-svn: 306916

Summary:
 removePartialRedundency optimization introduces a state in the
 RegisterCoalescer where an instruction pointed to in the WorkList
 is deleted from the MBB and then removed from the ErasedList.
 This patch updates the ErasedList to be used globally by not erasing
 erased Instructions from  it to solve the problem.

 The patch also accounts for the case where an Instruction was previously
 deleted and the same memory was reused by BuildMI to create a new instruction.

Reviewers: kparzysz, qcolombet

Reviewed By: qcolombet

Subscribers: MatzeB, qcolombet, llvm-commits

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

llvm-svn: 306915

Other Android CPUs probably pass just by luck as ulimit was not executed.

llvm-svn: 306914

llvm-svn: 306913

Summary:
Add an option to prevent diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for
large codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size. Discussion of
this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html

Reviewers: anemet, davidxl, hfinkel

Reviewed By: anemet

Subscribers: qcolombet, javed.absar, fhahn, eraman, llvm-commits

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

llvm-svn: 306912

[CodeView, PDB] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 306911

This reverts commit r306894.

Revert "[Dominators] Add NearestCommonDominator verification"

This reverts commit r306893.

Revert "[Dominators] Keep tree level in DomTreeNode and use it to find NCD and answer dominance queries"

This reverts commit r306892.

llvm-svn: 306907

It was not processing any value. All that it ever did was force
relocations, so name it shouldForceRelocation.

llvm-svn: 306906

Summary:
This patch aims to fix the bug reported at
https://bugs.llvm.org/show_bug.cgi?id=33189. Clang hits an assertion
when a template destructor declaration is present. This is caused by
later processing that does not expect to encounter a template when
looking at a destructor. The resolution is to treat the destructor as
being not declared when later processing is interested in the properties
of the destructor of a class.

Reviewers: rcraik, hubert.reinterpretcast, aaron.ballman, rsmith

Reviewed By: rsmith

Subscribers: rsmith, cfe-commits

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

Patch by Kuang He!

llvm-svn: 306905

llvm-svn: 306904

It was reverted in r305460 but the issue appears to only break our self-host
libcxx modules bot. Reapplying it will give us a chance to get a reproducer and
fix the issue.

llvm-svn: 306903

llvm-svn: 306899

Summary:
The lit test formats use largely the same logic for discovering tests. There are
some superficial differences in the logic, which seem reasonable enough to
handle in a single routine.

At a high level, the common goal is "look for files that end with one of these
suffixes, and skip anything starting with a dot." The balance of the logic
specific to ShTest and GoogleTest collapses quite a bit, so that
getTestsInDirectory is only a couple of lines around a call to the new function.

Reviewers: zturner, MatzeB, modocache

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 306895

Summary: This patch teaches IteratedDominanceFrontier to use the level information stored in DomTreeNodes instead of calculating it manually.

Reviewers: dberlin, sanjoy, davide

Reviewed By: davide

Subscribers: davide, llvm-commits

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

llvm-svn: 306894

Summary:
This patch adds another verification function for checking correctness of findNearestCommonDominator.
For every edge from U to V in the input graph, `NCD(U, V) == IDom(V) or V` -- the new function checks this condition.

Reviewers: dberlin, sanjoy, chandlerc

Reviewed By: dberlin

Subscribers: llvm-commits

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

llvm-svn: 306893

Summary:
This patch makes DomTreeNodes keep their level (depth) in the DomTree. By having this information always available, it is possible to speedup and simplify findNearestCommonDominator and certain dominance queries.

In the future, level information will be also needed to perform incremental updates.

My testing doesn't show any noticeable performance differences after applying this patch. There may be some improvements when other passes are thought to use the level information.

Reviewers: dberlin, sanjoy, chandlerc, grosser

Reviewed By: dberlin

Subscribers: llvm-commits

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

llvm-svn: 306892

llvm-svn: 306891

Type records have a unique type index, but symbol records do
not.  Instead, symbol records refer to other symbol records
by referencing their offset in the symbol stream.  In a sense
this is the analogue of the TypeIndex, but we are not printing
it in the dumper.  Printing it not only gives us more useful
information when manually investigating the contents of a PDB,
but also allows us to write better tests by enabling us to
verify that fields that reference other symbol records do
so correctly.

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

llvm-svn: 306890

If the instructions at the beginning of the block have no location,
we're better off using the location of the first instruction in the
current basic block. At the very least, that instruction post-dominates
this one, whereas if we don't emit a .cv_loc directive, we end up using
the potentially invalid location that falls through from the previous
block.

We could probably do better here by emitting some kind of ".cv_loc end"
directive that stops the line table entry of the previous .cv_loc
directive from bleeding out of its basic block. This would improve the
line table when an entire MBB has no valid location info.

llvm-svn: 306889

It applies to leaf functions that are otherwise not required to have
a frame pointer.

llvm-svn: 306888

llvm-svn: 306887

We aren't looking through any levels of IR here so I don't think we need the power of a matcher or the temporary variable it requires.

llvm-svn: 306885

Check if a single cast is preventing handling a first-order-recurrence Phi,
because the scheduling constraints it imposes on the first-order-recurrence
shuffle are infeasible; but they can be made feasible by moving the cast
downwards. Record such casts and move them when vectorizing the loop.

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

llvm-svn: 306884

The root cause of the issues reported in D32406 and D34680 is that clang
instruments functions without bodies. Make it stop doing that, and also
teach it how to use old (incorrectly generated) profiles without
crashing.

llvm-svn: 306883

llvm-svn: 306882

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306881

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306880

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306879

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding updates to clang, clang-tools-extra, and lld to follow.

llvm-svn: 306878

The llvm flag "-hexagon-emit-lookup-tables" guards the generation
of lookup table generated from a switch statement.
Differential Revision: https://reviews.llvm.org/D34819

llvm-svn: 306877

This adds all remaining instructions that were still missing, mostly
privileged and semi-privileged system-level instructions.  These are
provided for use with the assembler and disassembler only.

This brings the LLVM assembler / disassembler to parity with the
GNU binutils tools.

llvm-svn: 306876

It looks like there are two target-independent but not GISel instructions that
need legalization, IMPLICIT_DEF and PHI. These are already anomalies since
their operands have important LLTs attached, so to make things more uniform it
seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF.

llvm-svn: 306875

Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace

The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).

These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:

  class Foo
  {};

In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:

  class Foo
  { void Foo(); };

This is now properly formatted as:

  class Foo
  {
     void Foo();
  };

Reviewers: djasper, krasimir

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

llvm-svn: 306874

llvm-svn: 306873

This patch adds a new LLVM flag -hexagon-emit-jt-text which is defaulted to 
"false". The value "true" emits the switch generated jump tables in text section.
Differential Revision: https://reviews.llvm.org/D34820

llvm-svn: 306872

    
This reverts commit ae521f4192c3ed0202c047fec993cb59133dd1a0.
Wrong commit message

llvm-svn: 306871

The llvm flag "-hexagon-emit-lookup-tables" guards the generation
of lookup table from a switch statement.

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

llvm-svn: 306869

Summary:
This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:

  static int types[] = {
      registerType1(),
      registerType2(),
      registerType3(),
  };
  std::map<int, std::string> x = {
      { 0, "foo fjakfjaklf kljj" },
      { 1, "bar fjakfjaklf kljj" },
      { 2, "stuff fjakfjaklf kljj" },
  };

This is similar to how dictionnaries are formatted, and actually corresponds to the same conditions: when initializing a container (and not just 'calling' a constructor).

Such formatting involves 2 things:
* Line breaks around the content of the block. This can be forced by adding a comma or comment after the last element
* Elements should not be binpacked

This patch considers the block is an initializer list if it either ends with a comma, or follows an assignment, which seems to provide a sensible approximation.

Reviewers: krasimir, djasper

Reviewed By: djasper

Subscribers: malcolm.parsons, klimek, cfe-commits

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

llvm-svn: 306868

This patch appends the name of the function to the switch generated lookup
table. This will ease the visual debugging in identifying the function the table
is generated from.

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

llvm-svn: 306867

Summary:
Depends on https://reviews.llvm.org/D34865.

With the Clang uses of the old spelling having been removed in
https://reviews.llvm.org/D34865, get rid of the old "diagnostic hotness"
spellings in favor of the new "diagnostics hotness".

Reviewers: anemet, davidxl

Reviewed By: anemet

Subscribers: llvm-commits

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

llvm-svn: 306866