The existing matcher has lots of AT&T assembly dialect assumptions baked
into it.  In particular, the hack for resolving the size of a memory
operand by appending the four most common suffixes doesn't work at all.
The Intel assembly dialect mnemonic table has ambiguous entries, so we
need to try matching multiple times with different operand sizes, since
that's the only way to choose different instruction variants.

This makes us more compatible with gas's implementation of Intel
assembly syntax.  MSVC assumes you want byte-sized operations for the
instructions that we reject as ambiguous.

Reviewed By: grosbach

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

llvm-svn: 216481

PR 20642.

llvm-svn: 216475

proper flag.

llvm-svn: 216471

Thanks to David Blaikie for the suggestion.

llvm-svn: 216468

llvm-svn: 216466

The memory management in BugPoint is fairly convoluted, so this just unwraps
one layer by changing the return type of functions that always return
owned Modules.

llvm-svn: 216464

Just call parseBitcodeFile instead of getLazyBitcodeModule followed by
materializeAllPermanently.

llvm-svn: 216461

We had two functions for finding the temp or cache directory. Each had a
different set of smarts about OS specific APIs.

With this patch system_temp_directory becomes the only way to do it.

llvm-svn: 216460

llvm-svn: 216458

It seems on Darwin the illegal round-trip ::iterator -> MachineInstr* -> ::iterator breaks execution horribly when the iterator is not a real MachineInstr, like ::end().

llvm-svn: 216455

llvm-svn: 216451

(X >> Z) & (Y >> Z)  -> (X&Y) >> Z  for all shifts.
(X >> Z) | (Y >> Z)  -> (X|Y) >> Z  for all shifts.
(X >> Z) ^ (Y >> Z)  -> (X^Y) >> Z  for all shifts.

These patterns were previously handled separately in visitAnd()/visitOr()/visitXor().

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

llvm-svn: 216443

llvm-svn: 216442

Save InstCombine some work if we can perform this fold during
InstSimplify.

llvm-svn: 216441

consider:
long long *f(long long *b, long long *e) {
  return b + (e - b);
}

we would lower this to something like:
define i64* @f(i64* %b, i64* %e) {
  %1 = ptrtoint i64* %e to i64
  %2 = ptrtoint i64* %b to i64
  %3 = sub i64 %1, %2
  %4 = ashr exact i64 %3, 3
  %5 = getelementptr inbounds i64* %b, i64 %4
  ret i64* %5
}

This should fold away to just 'e'.

N.B.  This adds m_SpecificInt as a convenient way to match against a
particular 64-bit integer when using LLVM's match interface.

llvm-svn: 216439

Followup based on review.

llvm-svn: 216436

This reverts commit r216365.

llvm-svn: 216433

Address review comments.

llvm-svn: 216432

This reverts commit r216358.

llvm-svn: 216431

This reverts commit r216364.

llvm-svn: 216430

This reverts commit rr216359.

llvm-svn: 216429

This reverts commit r216360.

llvm-svn: 216428

llvm-svn: 216427

Address review comments.

llvm-svn: 216426

Also clean up and beef up this grep test for the feature.

llvm-svn: 216425

llvm-svn: 216424

Summary:
There is no functionality change here except in the way we assemble and
dump musttail calls in variadic functions. There's really no need to
separate out the bits for musttail and "is forwarding varargs" on call
instructions. A musttail call by definition has to forward the ellipsis
or it would fail verification.

Reviewers: chandlerc, nlewycky

Subscribers: llvm-commits

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

llvm-svn: 216423

llvm-svn: 216422

Adding, removing, or changing non-pack parameters can change the ABI
classification of pack parameters. Clang and other frontends encode the
classification in the IR of the call site, but the callee side
determines it dynamically based on the number of registers consumed so
far. Changing the prototype affects the number of registers consumed
would break such code.

Dead argument elimination performs a similar task and already has a
similar check to avoid this problem.

Patch by Thomas Jablin!

llvm-svn: 216421

The expressions 'Reloc.Addend - Addend' and 'Reloc.Offset' should always be
equal in this context. The latter is prefered - we want to remove the
RelocationValueRef::Addend field in the future.

llvm-svn: 216418

This patch fixes a subtle bug in the UNIX implementation of
llvm::sys::argumentsFitWithinSystemLimits() regarding the misuse of a static
variable. This bug causes our cached number that stores the system command line
maximum length to be halved after each call to the function. With a sufficient
number of calls to this function, it will eventually report any given command
line string to be over system limits.

Patch by Rafael Auler.

llvm-svn: 216415

Also switch section memory dump format from 8 to 16 columns.

llvm-svn: 216413

This patch refactors the argument serialization logic used in the Execute
function, used to launch new Windows processes. There is a critical step that
joins char** arguments into a single string, building the command line used to
launch the new process, and the readability of this code is improved if this
part is refactored in its own helper function.

Patch by Rafael Auler!

llvm-svn: 216411

llvm-svn: 216403

llvm-svn: 216400

Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.

A create static method would be even better, but this patch is already a bit too
big.

llvm-svn: 216393

This actually was caught by existing tests but those tests were disabled
with an XFAIL because of PR20736. While working on fixing that,
I noticed the test failure, and tracked it down to this.

We even have a really nice Clang warning that would have caught this but
it isn't enabled in LLVM! =[ I may look at enabling it.

llvm-svn: 216391

GlobalDCE deletes global vars and updates their initializers to nullptr
while leaving underlying constants to be cleaned up later by its uses.
The clean up may never happen, fix this by forcing it every time it's
safe to destroy constants.

Final patch by Rafael Espindola
http://reviews.llvm.org/D4931

<rdar://problem/17523868>

llvm-svn: 216390

llvm-svn: 216389

Patterns for lowering libm calls to VCVT{A,N,P,M} are also included.
Phabricator Revision: http://reviews.llvm.org/D5033

llvm-svn: 216388