AsmParser::ParseStatement.

Patch by Vladimir Medic.

llvm-svn: 159768

llvm-svn: 159767

This may turn out to be a controversial change, due to string literals being
uniqued at link time, but Apple's docs only say "The compiler makes such
object constants unique on a per-module basis..."[1] without actually saying
what a "module" is. (It's not a clang module.) Furthermore, this uniqueness
guarantee often can't be guaranteed once the string has been passed through
framework code.

If this does turn out very controversial, we could downgrade this to a
DefaultError warning for strings, and leave it as a true Error for other
kinds of literals.

(<rdar://problem/11300873>)

[1]: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/CreatingStrings.html

llvm-svn: 159766

used with classes that generate ASTConsumers; this allows decoupling
the ASTConsumer generation from the Frontend library (like, for example,
the MatchFinder in the upcoming ASTMatcher patch).

llvm-svn: 159760

llvm-svn: 159758

llvm-svn: 159754

llvm-svn: 159753

llvm-svn: 159752

Fix http://code.google.com/p/address-sanitizer/issues/detail?id=87 by making sure we replace the default CFAllocator only after __CFInitialize has been called.

llvm-svn: 159749

llvm-svn: 159748

llvm-svn: 159747

vector erase. No functionality changed.

llvm-svn: 159746

the key -- they are now stored in an IntervalMap.

I noticed this while looking into PR12652.

llvm-svn: 159745

llvm-svn: 159744

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