llvm-svn: 267292

This adds basic parsing of the EABI attributes section.  This section contains
additional information about the target for which the file was built.  Attempt
to infer additional architecture information from that section.

llvm-svn: 267291

clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp: Use raw_string_ostream::str() to flush the buffer explicitly.

llvm-svn: 267290

  Memory accesses can have non-precisely modeled access functions that
  would cause us to build incorrect execution context for hoisted loads.
  This is the same issue that occurred during the domain construction for
  statements and it is dealt with the same way.

llvm-svn: 267289

  The SCEVAffinator will now produce not only the isl representaiton of
  a SCEV but also the domain under which it is invalid. This is used to
  record possible overflows that can happen in the statement domains in
  the statements invalid domain. The result is that invalid loads have
  an accurate execution contexts with regards to the validity of their
  statements domain. While the SCEVAffinator currently is only taking
  "no-wrapping" assumptions, we can add more withouth worrying about the
  execution context of loads that are optimistically hoisted.

llvm-svn: 267288

llvm-svn: 267287

  The invalid context is not enough to describe the parameter constraints under
  which a statement is not modeled precisely. The reason is that during the
  domain construction the bounds on the induction variables are not known but
  needed to check if e.g., an overflow can actually happen. To this end we
  replace the invalid context of a statement with an invalid domain. It is
  initialized during domain construction and intersected with the domain once
  it was completely build. Later this invalid domain allows to eliminate
  falsely assumed wrapping cases and other falsely assumed mismatches in the
  modeling.

llvm-svn: 267286

  If the AssumptionContext is a subset of the InvalidContext the runtime
  context is not feasible.

llvm-svn: 267285

  If we know it is safe to execute a load we do not need an execution
  context, however only if we are sure it was modeled correctly.

llvm-svn: 267284

  These calls were sometimes costly and do not show any improvements on our
  small test cases.

llvm-svn: 267283

Currently failing due to poor blend matching, found whilst investigating PR27472

llvm-svn: 267282

%T expands to Output if not configured differently.

llvm-svn: 267281

[CodeGen] When promoting CTTZ operations to larger type, don't insert a select to detect if the input is zero to return the original size instead of the extended size. Instead just set the first bit in the zero extended part.

llvm-svn: 267280

Summary:
This removes a couple of flags added to control this behavior, and
simply keeps all value names when save-temps is specified.

Reviewers: rafael

Subscribers: llvm-commits, pcc, davide

Differential Revision: http://reviews.llvm.org/D19384

llvm-svn: 267279

Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.

Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references.  In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled.  This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).

Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves.  Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).

I've added two testcases:

  - test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
    test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
    instead of uniqued ones.  This confirms that, in the absence of
    uniqued nodes, distinct nodes are still emitted in post-order.

  - test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
    example where a naive post-order traversal would cause one uniqued
    node to forward-reference another.  IOW, it's the motivating test.

llvm-svn: 267278

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11700

llvm-svn: 267277

When an operand of a distinct node hasn't been read yet, the reader can
use a DistinctMDOperandPlaceholder.  This is much cheaper than forward
referencing from a uniqued node.  Change
ValueEnumerator::organizeMetadata to partition distinct nodes and
uniqued nodes to reduce the overhead of cycles broken by distinct nodes.

Mehdi measured this for me; this removes most of the RAUW from the
importing step of -flto=thin, even after a WIP patch that removes
string-based DITypeRefs (introducing many more cycles to the metadata
graph).

llvm-svn: 267276

http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36076

llvm-svn: 267275

llvm-svn: 267274

Summary:
As discussed in on the mailing list yesterday, I have refactored
BitcodeWriter.cpp to use classes to manage the bitcode writing process,
instead of passing around long lists of parameters between static
functions. See:
  http://lists.llvm.org/pipermail/llvm-dev/2016-April/098610.html

I created a parent BitcodeWriter class to own the BitstreamWriter,
write the header, and contain the main entry point into the writing
process. There are two derived classes, one for writing a module and one
for writing a combined index file (for ThinLTO), which manage the
writing process specific to those bitcode file types.

I also changed the functions to conform to LLVM coding standards
(lowercase function name first letter). The only two routines that still
start with an uppercase letter are the two external interfaces, which
can be fixed as a follow-on (I wanted to keep this round just within
BitcodeWriter.cpp).

Reviewers: dexonsmith, joker.eph

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D19447

llvm-svn: 267273

http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36074

llvm-svn: 267272

Mehdi's pattern recognition pulled this one out.  This is cleaner with
std::find_if than with the strange helper function that took an iterator
by reference and updated it.

llvm-svn: 267271

Each reference to an unresolved MDNode is expensive, since the RAUW
support in MDNode uses a separate allocation and side map.  Since
a distinct MDNode doesn't require its operands on creation (unlike
uniuqed nodes, there's no need to check for structural equivalence),
use nullptr for any of its unresolved operands.  Besides reducing the
burden on MDNode maps, this can avoid allocating temporary MDNodes in
the first place.

We need some way to track operands.  Invent DistinctMDOperandPlaceholder
for this purpose, which is a Metadata subclass that holds an ID and
points at its single user.  DistinctMDOperandPlaceholder::replaceUseWith
is just like RAUW, but its name highlights that there is only ever
exactly one use.

There is no support for moving (or, obviously, copying) these.  Move
support would be possible but expensive; leaving it unimplemented
prevents user error.  In the BitcodeReader I originally considered
allocating on a BumpPtrAllocator and keeping a vector of pointers to
them, and then I realized that std::deque implements exactly this.

A couple of obvious follow-ups:

  - Change ValueEnumerator to emit distinct nodes first to take more
    advantage of this optimization.  (How convenient... I think I might
    have a couple of patches for this.)

  - Change DIBuilder and its consumers (like CGDebugInfo in clang) to
    use something like this when constructing debug info in the first
    place.

llvm-svn: 267270

Prevent clang-format from moving the closing branch.

llvm-svn: 267269

Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT.  This change has NFC, but prepares for using IsDistinct
to optimize the behaviour of the getMD() and getMDOrNull() helpers.

llvm-svn: 267268

The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) that is
already caught by Verifier::visitDILocation.  The Verifier is a better
place for this anyway, and being inconsistent with other subclasses of
MDNode isn't serving anyone.

llvm-svn: 267267

[Hexagon] Set ctlz_zero_undef/cttz_zero_undef to Expand so LegalizeDAG will convert them to ctlz/cttz. Remove the now unneccessary isel patterns. NFC

llvm-svn: 267266

[NVPTX] Set ctlz_zero_undef to Expand so LegalizeDAG will convert it to ctlz. Remove the now unneccessary isel patterns. NFC

llvm-svn: 267265

[WebAssembly] Set ctlz_zero_undef/cttz_zero_undef to Expand so LegalizeDAG will convert them to ctlz/cttz. Remove the now unneccessary isel patterns. NFC

llvm-svn: 267264

Follow-on to r267262.

llvm-svn: 267263

I ran into this when seeing what tests would break if we make a
driver-level decision about whether FEPGO or IRPGO is the default.

llvm-svn: 267262

llvm-svn: 267261

llvm-svn: 267260

llvm-svn: 267259

llvm-svn: 267257

[sanitizer] add a function MmapNoAccess that mmaps a protected region *somewhere*; use MmapNoAccess in the Allocator when SpaceBeg is not a constant. In this mode the allocator will be a bit more hardened

llvm-svn: 267256

Previously, we have re-implemented utility functions such as `expect`
or `next` in LinkerScript.cpp. This patch reuses the existing
implementation that is in ScriptParser.cpp.

llvm-svn: 267255

llvm-svn: 267254

llvm-svn: 267253

[sanitizer] partially un-revert r267094: Allow the sanitizer allocator to use a non-fixed address range. An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point.

llvm-svn: 267252