hash_value overload for MachineOperands. This addresses a FIXME
sufficient for me to remove it, and cleans up the code nicely too.

The important changes to the hashing logic:
- TargetFlags are now included in all of the hashes. These were complete
  missed.
- Register operands have their subregisters and whether they are a def
  included in the hash.
- We now actually hash all of the operand types. Previously, many
  operand types were simply *dropped on the floor*. For example:
  - Floating point immediates
  - Large integer immediates (>64-bit)
  - External globals!
  - Register masks
  - Metadata operands
- It removes the offset from the block-address hash; I'm a bit
  suspicious of this, but isIdenticalTo doesn't consider the offset for
  black addresses.

Any patterns involving these entities could have triggered extreme
slowdowns in MachineCSE or PHIElimination. Let me know if there are PRs
you think might be closed now... I'm looking myself, but I may miss
them.

llvm-svn: 159743

corresponding clang warning.

llvm-svn: 159742

broken. This patch fixes the superficial problems which lead to the
intractably slow compile times reported in PR13225.

The specific issue is that we were failing to include the *offset* of
a global variable in the hash code. Oops. This would in turn cause all
MIs which were only distinguishable due to operating on different
offsets of a global variable to produce identical hash functions. In
some of the test cases attached to the PR I saw hash table activity
where there were O(1000) probes-per-lookup *on average*. A very few
entries were responsible for most of these probes.

There is still quite a bit more to do here. The ad-hoc layering of data
in MachineOperands makes them *extremely* brittle to hash correctly.
We're missing quite a few other cases, the only ones I've fixed here are
the specific MO types which were allowed through the assert() in
getOffset().

llvm-svn: 159741

booleans.  Patch by James Benton.

llvm-svn: 159739

First, placement new from standard library conflicts with our own.
Second, we are in trouble if user uses the same function (we either get instrumented code in runtime, or non-instrumented code in user program).

llvm-svn: 159738

llvm-svn: 159737

[tsan] fix compile-time falilure found while building Chromium with tsan (tsan issue #3). A unit test will follow separately.

llvm-svn: 159736

  Patched by JunQi<dengjunqi06323011@hotmail.com>.

llvm-svn: 159735

llvm-svn: 159734

actually perform value initialization rather than trying to fake it with a call
to the default constructor. Fixes various bugs related to the previously-missing
zero-initialization in this case.

I've also moved this and the other list initialization 'special case' from
TryConstructorInitialization into TryListInitialization where they belong.

llvm-svn: 159733

llvm-svn: 159732

[TSan] add a new option 'use_internal_symbolizer' that allows to choose between addr2line-based and llvm-based symbolizer w/o having to rebuild the runtime. This is hopefully a temporary solution that simplifies testing process. In the end, we should leave a single symbolizer.

llvm-svn: 159730

change.

Move the "Not profitable, avoid CSE!" debug message next to where we fail the
check for profitability and use a different message for avoiding CSE due to
being in different register classes.

llvm-svn: 159729

Function argument and return value registers aren't part of the
encoding, so they should be implicit operands.

llvm-svn: 159728

Also allow trailing register mask operands on non-variadic both
MachineSDNodes and MachineInstrs.

The extra physreg RegisterSDNode operands are added to the MI as
<imp-use> operands. This makes it possible to have non-variadic call
instructions.

Call and return instructions really are non-variadic, the argument
registers should only be used implicitly - they are not part of the
encoding.

llvm-svn: 159727

llvm-svn: 159726

Contributed by:  Yabin Hu  <yabin.hwu@gmail.com>

llvm-svn: 159725

llvm-svn: 159724

llvm-svn: 159723

Find the kill as the last terminator to read SrcReg.

Patch by Philipp Brüschweiler!

llvm-svn: 159722

The CopyToReg nodes that set up the argument registers before a call
must be glued to the call instruction. Otherwise, the scheduler may emit
the physreg copies long before the call, causing long live ranges for
the fixed registers.

Besides disabling good register allocation, that can also expose
problems when EmitInstrWithCustomInserter() splits a basic block during
the live range of a physreg.

llvm-svn: 159721

llvm-svn: 159720

No functionality change.

llvm-svn: 159719

This required moving the ctors for IntegerLiteral and FloatingLiteral out of
line which shouldn't change anything as they are usually called through Create
methods that are already out of line.

ASTContext::Deallocate has been a nop for a long time, drop it from ASTVector
and make it independent from ASTContext.h

Pass the StorageAllocator directly to AccessedEntity so it doesn't need to
have a definition of ASTContext around.

llvm-svn: 159718

Move the ASTContext-dependent version out of line.

llvm-svn: 159717

This avoids costly computation of getASTContext() and drops the header
dependency from DeclCXX.h to ASTContext.h.

llvm-svn: 159716

159509 and 159479 are reverted. It would be really nice to be able to run
just the coalescer :-(

llvm-svn: 159715

llvm-svn: 159714

These callbacks assume that the memory belongs to asan_zone, so it's incorrect to pass it to another one.
If a need for this appears (e.g. system libraries free the memory using wrong zone), it should be documented.

llvm-svn: 159713

class, from the target.  No functionality change, just less duplicated logic.

llvm-svn: 159710

llvm-svn: 159709

llvm-svn: 159708

llvm-svn: 159707

llvm-svn: 159706

Optimized diff operation: implemented the case when LHS and RHS subsets contains single numbers only.

llvm-svn: 159704

  IntegersSubsetMapping
  - Replaced type of Items field from std::list with std::map. In neares future I'll test it with DenseMap and do the correspond replacement
    if possible.

llvm-svn: 159703

llvm-svn: 159702

llvm-svn: 159701

we write into doesn't already exist.

<rdar://problem/11775508>

llvm-svn: 159700

from IfConversion.cc), and fix some spelling and grammar in the surrounding
prose.

llvm-svn: 159699