llvm-svn: 283430

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

llvm-svn: 283429

This commit fixes PR 30440 by initializing CXXNameMangler's FunctionTypeDepth
in the two constructors added in r274222 (The commit that caused this
regression).

rdar://28455269

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

llvm-svn: 283428

Cygwin has dlfcn.h, but no Dl_info

llvm-svn: 283427

This patch makes the check for null section stricter, 
so it is only allowed for STT_SECTION symbols now.

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

llvm-svn: 283426

Reviewers: ioeric

Subscribers: cfe-commits

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

llvm-svn: 283425

Summary:
cleanup the remaining empty namespace after moving out the
class defintitions.

Reviewers: ioeric

Subscribers: cfe-commits

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

llvm-svn: 283424

Global variables are GlobalValues, so they have explicit alignment. Querying
DataLayout for the alignment was incorrect.

Testcase added.

llvm-svn: 283423

We can work around a shortcoming of FileCheck by using {{\[}} to match a square
bracket before a [[ sequence.

Thanks to Eli Friedman for the heads up!

llvm-svn: 283422

llvm-svn: 283421

Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.

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

llvm-svn: 283420

Fuchsia is a new operating system.

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

llvm-svn: 283419

llvm-svn: 283418

llvm-svn: 283417

As a side effect, this avoid having to call .data() on the StringRef.

llvm-svn: 283416

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

llvm-svn: 283415

This one was my fault since I can't compile Android.

llvm-svn: 283414

This is better for a number of reasons.  Mostly style, but also:

1) Signed-unsigned comparison warnings disappear since there is
   no loop index.
2) Iterating with the range-for style gives you back an entry
   that has more than just a const char*, so it's more efficient
   and more useful.
3) Makes code safter since the type system enforces that it's
   impossible to index out of bounds.

llvm-svn: 283413

llvm-svn: 283411

The AVX attribute is added to remove noise caused by SSE's destructive insts.  

llvm-svn: 283410

llvm-svn: 283409

Summary:
The current implementation of `hash_code()` for uniqued RTTI strings violates strict aliasing by dereferencing a type-punned pointer. Specifically it generates a `const char**` pointer from the address of the `__name` member before casting it to `const size_t*` and dereferencing it to get the hash. This is really just a complex and incorrect way of writing `reinterpret_cast<size_t>(__name)`.

This patch changes the conversion sequence so that it no longer contains UB.


Reviewers: howard.hinnant, mclow.lists

Subscribers: rjmccall, cfe-commits

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

llvm-svn: 283408

We need to match file names with both forward and backward slashes.

llvm-svn: 283407

new expression, distinguish between the case of a constant and non-constant
initializer. In the former case, if the bound is erroneous (too many
initializer elements, bound is negative, or allocated size overflows), reject,
and take the bound into account when determining whether we need to
default-construct any elements. In the remanining cases, move the logic to
check for default-constructibility of trailing elements into the initialization
code rather than inventing a bogus array bound, to cope with cases where the
number of initialized elements is not the same as the number of initializer
list elements (this can happen due to string literal initialization or brace
elision).

This also fixes rejects-valid and crash-on-valid errors when initializing a
new'd array of character type from a braced string literal.

llvm-svn: 283406

llvm-svn: 283405

insturction profiling.  Add a test that verifies that we reject a
32-bit only instruction in 64-bit (long) mode.

This wraps up all the testing I want to add for 
x86AssemblyInspectionEngine.

llvm-svn: 283404

If we don't truncate, LLVM asserts when the label difference doesn't fit
in a 16 bit field. This patch truncates two kinds of data: trailing null
terminated names in symbol records, and inline line tables. The inline
line table test that I have is too large (many MB), so I'm not checking
it in.

Hopefully fixes PR28264.

llvm-svn: 283403

How code is optimized sometimes, perhaps often, depends on the context into
which it was inlined. This change allows llvm-opt-report to track the
differences between the optimizations performed, or not, in different contexts,
and when these differ, display those differences.

For example, this code:

  $ cat /tmp/q.cpp
  void bar();
  void foo(int n) {
    for (int i = 0; i < n; ++i)
      bar();
  }

  void quack() {
    foo(4);
  }

  void quack2() {
    foo(4);
  }

will now produce this report:

  < /home/hfinkel/src/llvm/test/tools/llvm-opt-report/Inputs/q.cpp
   2         | void bar();
   3         | void foo(int n) {
   [[
    > foo(int):
   4         |   for (int i = 0; i < n; ++i)
    > quack(), quack2():
   4  U4     |   for (int i = 0; i < n; ++i)
   ]]
   5         |     bar();
   6         | }
   7         |
   8         | void quack() {
   9 I       |   foo(4);
  10         | }
  11         |
  12         | void quack2() {
  13 I       |   foo(4);
  14         | }
  15         |

Note that the tool has demangled the function names, and grouped the reports
associated with line 4. This shows that the loop on line 4 was unrolled by a
factor of 4 when inlined into the functions quack() and quack2(), but not in
the function foo(int) itself.

llvm-svn: 283402

This came out of a discussion in https://reviews.llvm.org/D25285.

There used to be various other llvm.dbg.* nodes, but we don't support
upgrading them and we want to reserve the namespace for future uses.

This also removes an entirely obsolete and bitrotted testcase for PR7662.

Reapplies 283390 with a forgotten testcase.

llvm-svn: 283400

Forgot to add a testcase in r283390.

llvm-svn: 283399

LLVM now has the ability to record information from optimization remarks in a
machine-consumable YAML file for later analysis. This can be enabled in opt
(see r282539), and D25225 adds a Clang flag to do the same. This patch adds
llvm-opt-report, a tool to generate basic optimization "listing" files
(annotated sources with information about what optimizations were performed)
from one of these YAML inputs.

D19678 proposed to add this capability directly to Clang, but this more-general
YAML-based infrastructure was the direction we decided upon in that review
thread.

For this optimization report, I focused on making the output as succinct as
possible while providing information on inlining and loop transformations. The
goal here is that the source code should still be easily readable in the
report. My primary inspiration here is the reports generated by Cray's tools
(http://docs.cray.com/books/S-2496-4101/html-S-2496-4101/z1112823641oswald.html).
These reports are highly regarded within the HPC community. Intel's compiler,
for example, also has an optimization-report capability
(https://software.intel.com/sites/default/files/managed/55/b1/new-compiler-optimization-reports.pdf).

  $ cat /tmp/v.c
  void bar();
  void foo() { bar(); }

  void Test(int *res, int *c, int *d, int *p, int n) {
    int i;

  #pragma clang loop vectorize(assume_safety)
    for (i = 0; i < 1600; i++) {
      res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
    }

    for (i = 0; i < 16; i++) {
      res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
    }

    foo();

    foo(); bar(); foo();
  }

D25225 adds -fsave-optimization-record (and
-fsave-optimization-record=filename), and this would be used as follows:

  $ clang -O3 -o /tmp/v.o -c /tmp/v.c -fsave-optimization-record
  $ llvm-opt-report /tmp/v.yaml > /tmp/v.lst
  $ cat /tmp/v.lst

  < /tmp/v.c
   2          | void bar();
   3          | void foo() { bar(); }
   4          |
   5          | void Test(int *res, int *c, int *d, int *p, int n) {
   6          |   int i;
   7          |
   8          | #pragma clang loop vectorize(assume_safety)
   9     V4,2 |   for (i = 0; i < 1600; i++) {
  10          |     res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
  11          |   }
  12          |
  13  U16     |   for (i = 0; i < 16; i++) {
  14          |     res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
  15          |   }
  16          |
  17 I        |   foo();
  18          |
  19          |   foo(); bar(); foo();
     I        |   ^
     I        |                 ^
  20          | }

Each source line gets a prefix giving the line number, and a few columns for
important optimizations: inlining, loop unrolling and loop vectorization. An
'I' is printed next to a line where a function was inlined, a 'U' next to an
unrolled loop, and 'V' next to a vectorized loop. These are printed on the
relevant code line when that seems unambiguous, or on subsequent lines when
multiple potential options exist (messages, both positive and negative, from
the same optimization with different column numbers are taken to indicate
potential ambiguity). When on subsequent lines, a '^' is output in the relevant
column.

Annotated source for all relevant input files are put into the listing file
(each starting with '<' and then the file name).

You can disable having the unrolling/vectorization factors appear by using the
-s flag.

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

llvm-svn: 283398

llvm-svn: 283397

Fixes rdar://28237467

llvm-svn: 283396

llvm-svn: 283395

Ten days.

llvm-svn: 283394

But we have node-level FMF, so the next step is to fix this at the instruction/node-level.

llvm-svn: 283393

With this, "llvm-pdbdump yaml -ipi-stream" prints out an IPI stream.
Previously it crashed because it can't handle the case where IPI
stream doesn't exist.

llvm-svn: 283392

Summary: This makes a change to the state used to maintain visited information for depth first iterator. We know assume a method "completed(...)" which is called after all children of a node have been visited. In all existing cases, this method does nothing so this patch has no functional changes.  It will however allow a client to distinguish back from cross edges in a DFS tree.

Reviewers: nadav, mehdi_amini, dberlin

Subscribers: MatzeB, mzolotukhin, twoh, freik, llvm-commits

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

llvm-svn: 283391

This came out of a discussion in https://reviews.llvm.org/D25285.

There used to be various other llvm.dbg.* nodes, but we don't support
upgrading them and we want to reserve the namespace for future uses.

This also removes an entirely obsolete and bitrotted testcase for PR7662.

llvm-svn: 283390

llvm-svn: 283389