This broke in r144788 when the CodeGenOpt option was moved from everywhere else
(specifically, from addPassesToEmitFile) to createTargetMachine. Since
LTOCodeGenerator wasn't passing the 4th argument, when the 4th parameter became
the 3rd, it silently continued to compile (int->bool conversion) but meant
something completely different.

This change preserves the existing (accidental) and previous (default)
semantics of the addPassesToEmitFile and restores the previous/intended
CodeGenOpt argument by passing it appropriately to createTargetMachine.

(discovered by pending changes to -Wconversion to catch constant->bool
conversions)

llvm-svn: 157705

llvm-svn: 157704

It is better to address sub-registers directly by name instead of
relying on their position in the sub-register list.

llvm-svn: 157703

An empty list is not represented as a null pointer. Let TRI do its own
shortcuts.

llvm-svn: 157702

This also required making recursive simplifications until
nothing changes or a hard limit (currently 3) is hit.

With the simplification in place indvars can canonicalize
loops of the form
for (unsigned i = 0; i < a-b; ++i)
into
for (unsigned i = 0; i != a-b; ++i)
which used to fail because SCEV created a weird umax expr
for the backedge taken count.

llvm-svn: 157701

it's pointed out that R11 can be used for magic things, and doing things just for 64-bit registers is silly.  Just optimize 3 more.

llvm-svn: 157699

integer registers.  This is already supported by the fastcc convention, but it doesn't
hurt to support it in the standard conventions as well.

In cases where we can cheat at the calling convention, this allows us to avoid returning
things through memory in more cases.

llvm-svn: 157698

Patch by Jush Lu <jush.msn@gmail.com>.

llvm-svn: 157696

Also add subclasses MCSubRegIterator, MCSuperRegIterator, and
MCRegAliasIterator.

These iterators provide an abstract interface to the MCRegisterInfo
register lists so the internal representation can be changed without
changing all clients.

llvm-svn: 157695

llvm-svn: 157688

llvm-svn: 157685

llvm-svn: 157684

llvm-svn: 157683

If integer overflow causes one of the terms to reach zero, that can
force the entire expression to zero.

Fixes PR12929: cast<Ty>() argument of incompatible type

llvm-svn: 157673

No functionality.

llvm-svn: 157672

llvm-svn: 157663

If-converter models predicated defs as read + write. The read should be marked as 'undef' since it may not already be live. This appeases -verify-machineinstrs.

llvm-svn: 157662

llvm-svn: 157661

Besides adding the new insertPass function, this patch uses it to
enhance the existing -print-machineinstrs so that the MachineInstrs
after a specific pass can be printed.

Patch by Bin Zeng!

llvm-svn: 157655

Apparently, a friend can't derive from a private class according to gcc.

llvm-svn: 157654

The register unit lists are typically much shorter than the register
overlap lists, and the backing table for register units has better cache
locality because it is smaller.

This makes llc about 0.5% faster. The regsOverlap() function isn't that hot.

llvm-svn: 157651

Register units are already used internally in TableGen to compute
register pressure sets and overlapping registers. This patch makes them
available to the code generators.

The register unit lists are differentially encoded so they can be reused
for many related registers. This keeps the total size of the lists below
200 bytes for most targets. ARM has the largest table at 560 bytes.

Add an MCRegUnitIterator for traversing the register unit lists. It
provides an abstract interface so the representation can be changed in
the future without changing all clients.

llvm-svn: 157650

 - hoist checks out of loops where SCEV is smart enough
 - add additional statistics to measure how much we loose for not supporting interprocedural and pointers loaded from memory

llvm-svn: 157649

llvm-svn: 157644

llvm-svn: 157640

Add intrinsics, code gen, assembler and disassembler support for the SSE4a extrq and insertq instructions.

This required light surgery on the assembler and disassembler
because the instructions use an uncommon encoding. They are
the only two instructions in x86 that use register operands
and two immediates.

llvm-svn: 157634

ranges for the instruction about to be bundled. This fixes a bug in an external
project where an assertion was triggered due to spurious 'multiple defs' within
the bundle.

Patch by Ivan Llopard. Thanks Ivan!

llvm-svn: 157632

llvm-svn: 157624

llvm-svn: 157612

llvm-svn: 157594

llvm-svn: 157592

The test case feeds the following into InstCombine's visitSelect:
%tobool8 = icmp ne i32 0, 0
%phitmp = select i1 %tobool8, i32 3, i32 0
Then instcombine replaces the right side of the switch with 0, doesn't notice
that nothing changes and tries again indefinitely.

This fixes PR12897.

llvm-svn: 157587

llvm-svn: 157586

Attribute bits above 1<<30 are now encoded correctly.  Additionally,
the encoding/decoding functionality has been hoisted to helper functions
in Attributes.h in an effort to help the encoding/decoding to stay in
sync with the Attribute bitcode definitions.

llvm-svn: 157581

llvm-svn: 157577

Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now?
1. It will very difficult to implement case ranges as series of small patches. We got several large and heavy patches. Each patch will about 90-120 kb. If you replace ConstantInt with APInt in SwitchInst you will need to changes at the same time all Readers,Writers and absolutely all passes that uses SwitchInst.
2. We can implement APInt pool inside and save memory space. E.g. we use several switches that works with 256 bit items (switch on signatures, or strings). We can avoid value duplicates in this case.
3. IntItem can be easyly easily replaced with APInt.
4. Currenly we can interpret IntItem both as ConstantInt and as APInt. It allows to provide SwitchInst methods that works with ConstantInt for non-updated passes.

Why I need it right now? Currently I need to update SimplifyCFG pass (EqualityComparisons). I need to work with APInts directly a lot, so peaces of code
ConstantInt *V = ...;
if (V->getValue().ugt(AnotherV->getValue()) {
  ...
}
will look awful. Much more better this way:
IntItem V = ConstantIntVal->getValue();
if (AnotherV < V) {
}

Of course any reviews are welcome.

P.S.: I'm also going to rename ConstantRangesSet to IntegersSubset, and CRSBuilder to IntegersSubsetMapping (allows to map individual subsets of integers to the BasicBlocks).
Since in future these classes will founded on APInt, it will possible to use them in more generic ways.

llvm-svn: 157576

llvm-svn: 157575

replicating the code for every place it's needed, we instead generate a function
that does that for us. This function is local to the executable, so there
shouldn't be any writing violations.

llvm-svn: 157564

llvm-svn: 157556

llvm-svn: 157555