Accepting quotes is a property of an assembler, not of an object file. For
example, ELF can support any names for sections and symbols, but the gnu
assembler only accepts quotes in some contexts and llvm-mc in a few more.

LLVM should not produce different symbols based on a guess about which assembler
will be reading the code it is printing.

llvm-svn: 194575

verifyFunction needs to call doInitialization to collect metadata and avoid
crashing when verifying debug info in a function.

But it should not call doFinalization since that is where the verifier will
check declarations, variables and aliases, which is not desirable when one
only wants to verify a function.

A possible cleanup would be to split the class into a ModuleVerifier and
FunctionVerifier.

Issue reported by Ilia Filippov. Patch by Michael Kruse.

llvm-svn: 194574

Fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994, which hadn't
manifested in LLVM because libclang_rt.asan_osx_dynamic.dylib used to depend on
the Foundation framework.
Without that dependency some interceptors may be called from the system
libraries before libSystem_initializer() is called, which lead to assertion
failures in sanitizer_mac.cc (_NSGetEnviron() returns NULL).

To fix the problem we fall back to the original functions in the common
libsanitizer interceptors and the __cxa_atexit() interceptor on Darwin.

This patch also prints a better error message in the case _NSGetEnviron()
returns NULL.

llvm-svn: 194573

llvm-svn: 194572

This allows compilation database implementations for distributed build
systems to hand all data to the client to make parsing independent of
the file system.

llvm-svn: 194571

llvm-svn: 194570

llvm-svn: 194569

llvm-svn: 194568

This adds a new option -fprofile-sample-use=filename to Clang. It
tells the driver to schedule the SampleProfileLoader pass and passes
on the name of the profile file to use.

llvm-svn: 194567

This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.

The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.

External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.

The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains.  This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.

To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.

The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.

Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.

This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.

Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.

This patch implements:

- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
  generates branch weight metadata on every branch instructions that
  matches the profiles.
- A text loader class to assist the implementation of
  SampleProfile::loadText().
- Basic unit tests for the pass.

Additionally, the patch uses profile information to compute branch
weights based on instruction samples.

This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:

Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.

Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.

I will adjust this assignment in subsequent patches.

llvm-svn: 194566

Summary:
This fixes a subtle bug in new FileCheck feature added
in r194343. When we search for the first satisfying check-prefix,
we should actually return the first encounter of some check-prefix as a
substring, even if it's not a part of valid check-line. Otherwise
"FileCheck --check-prefix=FOO --check-prefix=BAR" with check file:

  FOO not a vaild check-line
  FOO: foo
  BAR: bar

incorrectly accepted file:

  fog
  bar

as it skipped the first two encounters of FOO, matching only BAR: line.

Reviewers: arsenm, dsanders

Reviewed By: dsanders

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2166

llvm-svn: 194565

llvm-svn: 194564

llvm-svn: 194563

This patch fixes a bug in floating point operands parsing, when instruction alias uses default register operand.

llvm-svn: 194562

They are failing on clang-native-arm-cortex-a9.

Please tweak MCJIT/lit.local.cfg, if this didn't satisfy bots.

llvm-svn: 194561

No functionality change.

llvm-svn: 194560

This patch fixes PR8264. Duplicate qualifiers already are diagnozed,
now the same diagnostics is issued for duplicate function specifiers.

Differential Revision: http://llvm-reviews.chandlerc.com/D2025

llvm-svn: 194559

They are reported as XPASSing.

llvm-svn: 194558

Also, prune <stdlib.h>, seems stray.

llvm-svn: 194557

llvm-svn: 194556

specifically about the .space directive. This allows us to force large
blocks of code to appear in test cases for things like constant islands
without having to make giant test cases to force things like long 
branches to take effect.

llvm-svn: 194555

Per discussion with Chris Lattner

llvm-svn: 194554

llvm-svn: 194553

This reverts commit r194551 because it broke the buildbot.

llvm-svn: 194552

llvm-svn: 194551

llvm-svn: 194550

llvm-svn: 194549

This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.

llvm-svn: 194548

llvm-svn: 194547

llvm-svn: 194546

llvm-svn: 194545

Implement a "memory find" command for LLDB

This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in
mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r

llvm-svn: 194544

llvm-svn: 194543

This patch reapplies r193676 with an additional fix for the Hexagon backend. The
SystemZ backend has already been fixed by r194148.

The Type Legalizer recognizes that VSELECT needs to be split, because the type
is to wide for the given target. The same does not always apply to SETCC,
because less space is required to encode the result of a comparison. As a result
VSELECT is split and SETCC is unrolled into scalar comparisons.

This commit fixes the issue by checking for VSELECT-SETCC patterns in the DAG
Combiner. If a matching pattern is found, then the result mask of SETCC is
promoted to the expected vector mask type for the given target. Now the type
legalizer will split both VSELECT and SETCC.

This allows the following X86 DAG Combine code to sucessfully detect the MIN/MAX
pattern. This fixes PR16695, PR17002, and <rdar://problem/14594431>.

Reviewed by Nadav

llvm-svn: 194542

pattern in use here. Addresses review feedback from Sean (thanks!) and
others.

llvm-svn: 194541

expression that is not a zero literal, in C. Patch by Ivan A. Kosarev!

llvm-svn: 194540

llvm-svn: 194539

more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

llvm-svn: 194538

llvm-svn: 194537

pair, and a couple of pair-like implementation detail types.  The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.

Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors.  Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm).   This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.

Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members.  However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).

During this work a bug was also found and fixed in
is_trivially_constructible.

And there is a minor drive-by fix in <__config> regarding
__type_visibility__.

A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11.  This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.

llvm-svn: 194536