llvm-svn: 188386

When determining if two different loads are from the same base address,
this patch allows one load to use a t2LDRi8 address mode and another to
use a t2LDRi12 address mode. The current implementation is very
conservative and this allows the case of differing Thumb2 byte loads to
be considered. Allowing these differing modes instead of forcing the exact
same opcode is useful for situations where one opcodes loads from a base
address+1 and a second opcode loads for a base address-1.

Patch by Daniel Stewart.

llvm-svn: 188385

 - Now fixed to ensure substitution value isn't of unicode type on Python 2.6-7.

llvm-svn: 188384

llvm-svn: 188383

llvm-svn: 188382

llvm-svn: 188381

llvm-svn: 188380

Revert r188376, "[lit] Support parsing scripts with inconsistent or invalid encodings.", this doesn't work yet for bots using the internal shell.

llvm-svn: 188379

llvm-svn: 188378

As Ben pointed out, GAS doesn't support this syntax so we should give at least
some warning that it might not be portable.

llvm-svn: 188377

 - For whatever reason, we have a lot of test files with bogus unicode
   characters. This patch allows those scripts to still be parsed on Python3 by
   changing the parsing logic to work on binary files, and only require the
   actual script commands to be convertible to ascii.

llvm-svn: 188376

llvm-svn: 188375

A missed clause in an error test added in r188371 caused any use of the
migrator requesting multiple transforms to fail.

llvm-svn: 188374

It caused "shell parser error" on win32 internal shell. ShParser doesn't expect unicode, but str.

llvm-svn: 188373

Somehow I forgot to test one of the error conditions I'd added.

llvm-svn: 188372

For use with -headers, -yaml-only will cause cpp11-migrate to not write header
changes to disk and instead write them as header change description files. This
option facilitiates upcoming functionality to properly support changing headers
as part of migration.

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

llvm-svn: 188371

It's useful to be able to write down floating-point numbers without having to
worry about what they'll be rounded to (as C99 discovered), this extends that
ability to the MC assembly parsers.

llvm-svn: 188370

This change moves everything depending on kernel headers (mostly ioctl types
and ids) into a separate source file. This will reduce the possibility of
header conflict on various platforms (most importantly, older glibc versions).

This change also removes 2 deprecated ioctls, and symbolic ids for other bunch
of ambiguous ioctls (i.e. same id is shared by ioctls with different memory
behavior).

llvm-svn: 188369

Found by -Wdocumentation.

llvm-svn: 188368

extremely subtle miscompilations (such as a load getting replaced with
the value stored *below* the load within a basic block) related to
promoting an alloca to an SSA value, there is the dim possibility that
you hit this. Please let me know if you won this unfortunate lottery.

The first half of mem2reg's core logic (as it is used both in the
standalone mem2reg pass and in SROA) builds up a mapping from
'Instruction *' to the index of that instruction within its basic block.
This allows quickly establishing which store dominate a particular load
even for large basic blocks. We cache this information throughout the
run of mem2reg over a function in order to amortize the cost of
computing it.

This is not in and of itself a strange pattern in LLVM. However, it
introduces a very important constraint: absolutely no instruction can be
deleted from the program without updating the mapping. Otherwise a newly
allocated instruction might get the same pointer address, and then end
up with a wrong index. Yes, LLVM routinely suffers from a *single
threaded* variant of the ABA problem. Most places in LLVM don't find
avoiding this an imposition because they don't both delete and create
new instructions iteratively, but mem2reg *loves* to do this... All the
time. Fortunately, the mem2reg code was really careful about updating
this cache to handle this eventuallity... except when it comes to the
debug declare intrinsic. Oops. The fix is to invalidate that pointer in
the cache when we delete it, the same as we do when deleting alloca
instructions and other instructions.

I've also caused the same bug in new code while working on a fix to
PR16867, so this seems to be a really unfortunate pattern. Hopefully in
subsequent patches the deletion of dead instructions can be consolidated
sufficiently to make it less likely that we'll see future occurences of
this bug.

Sorry for not having a test case, but I have literally no idea how to
reliably trigger this kind of thing. It may be single-threaded, but it
remains an ABA problem. It would require a really amazing number of
stars to align.

llvm-svn: 188367

llvm-svn: 188366

llvm-svn: 188365

llvm-svn: 188364

llvm-svn: 188363

Replace EVT with MVT in isVectorShift. Keeps compiler from generating unneeded checks and handling for extended types.

llvm-svn: 188362

Replace EVT with MVT in many of the shuffle lowering functions. Keeps compiler from generating unneeded checks and handling for extended types.

llvm-svn: 188361

llvm-svn: 188360

 - We barely used it, and it is very hard to use in a 2.5-3 compatible
   way because of changing expectations for its input types.

llvm-svn: 188359

llvm-svn: 188358

llvm-svn: 188357

llvm-svn: 188356

llvm-svn: 188355

llvm-svn: 188354

llvm-svn: 188353

The rationale for this change is to differentiate following two situations:
  1) clang -c -emit-llvm a.c
  2) clang -c -flto a.c 

Reviewed by Eric Christopher. Thanks a lot!

llvm-svn: 188352

[CMake] add_llvm_library: Specify explicit suffix .imp to import library to avoid a warning between profile_rt-static and profile_rt-shared with lib/profile_rt.lib.

FIXME: It seems MS version of profile_rt.dll doesn't contain any export symbols.
llvm-svn: 188351

llvm-svn: 188350

clang-tools-extra/test/cpp11-migrate/HeaderReplacements/main.cpp: Use "%/t" instead of "%t" on sed(1) to avoid \'s expanded to control chars.

The feature, "%/t", has been introduced in llvm/lit since r188348.

llvm-svn: 188349

llvm-svn: 188348

llvm-svn: 188347