[DAG] Don't pull the binary operation though the shift if the operands have opaque constants.

During DAGCombine visitShiftByConstant assumes that certain binary operations
with only constant operands can always be folded successfully. This is no longer
true when the constant is opaque. This commit fixes visitShiftByConstant by not
performing the optimization for opaque constants. Otherwise we would end up in
an infinite DAGCombine loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200900 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Wire up the analysis managers in the opt driver. This isn't really
necessary until we add analyses to the driver, but I have such an
analysis ready and wanted to split this out. This is actually exercised
by the existing tests of the new pass manager as the analysis managers
are cross-checked and validated by the function and module managers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200901 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Back out one hunk of the patch in r200901 that was *supposed* to go
in my next patch. Sorry for the breakage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200902 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Add a new "lazy" call graph analysis pass for the new pass manager.

The primary motivation for this pass is to separate the call graph
analysis used by the new pass manager's CGSCC pass management from the
existing call graph analysis pass. That analysis pass is (somewhat
unfortunately) over-constrained by the existing CallGraphSCCPassManager
requirements. Those requirements make it *really* hard to cleanly layer
the needed functionality for the new pass manager on top of the existing
analysis.

However, there are also a bunch of things that the pass manager would
specifically benefit from doing differently from the existing call graph
analysis, and this new implementation tries to address several of them:

- Be lazy about scanning function definitions. The existing pass eagerly
  scans the entire module to build the initial graph. This new pass is
  significantly more lazy, and I plan to push this even further to
  maximize locality during CGSCC walks.
- Don't use a single synthetic node to partition functions with an
  indirect call from functions whose address is taken. This node creates
  a huge choke-point which would preclude good parallelization across
  the fanout of the SCC graph when we got to the point of looking at
  such changes to LLVM.
- Use a memory dense and lightweight representation of the call graph
  rather than value handles and tracking call instructions. This will
  require explicit update calls instead of some updates working
  transparently, but should end up being significantly more efficient.
  The explicit update calls ended up being needed in many cases for the
  existing call graph so we don't really lose anything.
- Doesn't explicitly model SCCs and thus doesn't provide an "identity"
  for an SCC which is stable across updates. This is essential for the
  new pass manager to work correctly.
- Only form the graph necessary for traversing all of the functions in
  an SCC friendly order. This is a much simpler graph structure and
  should be more memory dense. It does limit the ways in which it is
  appropriate to use this analysis. I wish I had a better name than
  "call graph". I've commented extensively this aspect.

This is still very much a WIP, in fact it is really just the initial
bits. But it is about the fourth version of the initial bits that I've
implemented with each of the others running into really frustrating
problms. This looks like it will actually work and I'd like to split the
actual complexity across commits for the sake of my reviewers. =] The
rest of the implementation along with lots of wiring will follow
somewhat more rapidly now that there is a good path forward.

Naturally, this doesn't impact any of the existing optimizer. This code
is specific to the new pass manager.

A bunch of thanks are deserved for the various folks that have helped
with the design of this, especially Nick Lewycky who actually sat with
me to go through the fundamentals of the final version here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200903 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Fix horrible typos that somehow didn't cause a failure in a C++11
build but spectacularly changed behavior of the C++98 build. =]

This shows my one problem with not having unittests -- basic API
expectations aren't well exercised by the integration tests because they
*happen* to not come up, even though they might later. I'll probably add
a basic unittest to complement the integration testing later, but
I wanted to revive the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200905 91177308-0d34-0410-b5e6-96231b3b80d8
Delete all of the CodeGenInstructions from CodeGenTarget destructor.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200906 91177308-0d34-0410-b5e6-96231b3b80d8
A memcpy out of an fresh alloca is a no-op, delete it. Patch by Patrick Walton!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200907 91177308-0d34-0410-b5e6-96231b3b80d8
This small change reduces compile time for small programs on targets that have
large register files. The omission of Queries.clear() is perfectly safe because
LiveIntervalUnion::Query doesn't contain any data that needs freeing and
because LiveRegMatrix::runOnFunction happens to reset the OwningArrayPtr
holding Queries every time it is run, so there's no need to zero out the
queries either. Not having to do this for very large numbers of physregs
is a noticeable constant cost reduction in compilation of small programs.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200913 91177308-0d34-0410-b5e6-96231b3b80d8
The following patch' purpose is to reduce compile time for compilation of small
programs on targets with large register files. The root of the compile time
overhead was in the use of llvm::SmallVector to hold PhysRegEntries, which
resulted in slow-down from calling llvm::SmallVector::assign(N, 0). In contrast
std::vector uses the faster __platform_bzero to zero out primitive buffers when
assign is called, while SmallVector uses an iterator.

The fix for this was simply to replace the SmallVector with a dynamically
allocated buffer and to initialize or reinitialize the buffer based on the
total registers that the target architecture requires. The changes support
cases where a pass manager may be reused for different targets, and note that
the PhysRegEntries is allocated using calloc mainly for good for, and also to
quite tools like Valgrind (see comments for more info on this).

There is an rdar to track the fact that SmallVector doesn't have platform
specific speedup optimizations inside of it for things like this, and I'll
create a bugzilla entry at some point soon as well.

TL;DR: This fix replaces the expensive llvm::SmallVector<unsigned
char>::assign(N, 0) with a call to calloc for N bytes which is much faster
because SmallVector's assign uses iterators.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200917 91177308-0d34-0410-b5e6-96231b3b80d8
X86: deduplicate V[SZ]EXT_MOVL and V[SZ]EXT nodes

I believe VZEXT_MOVL means "zero all vector elements except the first" (and
should have identical input & output types) whereas VZEXT means "zero extend
each element of a vector (discarding higher elements if necessary)".

For example:
    (v4i32 (vzext (v16i8 ...)))

should zero extend the low 4 bytes of the incoming vector to 32-bits,
discarding higher bytes.

However, somewhere in the past, these two concepts had become confused, even
leading to a nonsensical VSEXT_MOVL.

This re-merges the nodes where appropriate (all VSEXT_MOVL -> VSEXT, VZEXT_MOVL
-> VZEXT when it's an actual extension).

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200918 91177308-0d34-0410-b5e6-96231b3b80d8
Yet another patch to reduce compile time for small programs:

The aim in this patch is to reduce work that VirtRegRewriter needs to do when
telling MachineRegisterInfo which physregs are in use. Up until now
VirtRegRewriter::rewrite has been doing rewriting and populating def info and
then proceeding to set whether a physreg is used based this info for every
physreg that the target provides. This can be expensive when a target has an
unusually high number of supported physregs, and is a noticeable chunk of
compile time for small programs on such targets.

So to reduce compile time, this patch simply adds the use of a SparseSet to the
rewrite function that is used to flag each physreg that is encountered in a
MachineFunction. Afterward, rather than iterating over the set of all physregs
for a given target to set the physregs used in MachineRegisterInfo, the new way
is to iterate over the set of physregs that were actually encountered and set
in the SparseSet. This improves compile time because the existing rewrite
function was iterating over all MachineOperands already, and because the
iterations afterward to setPhysRegUsed is reduced by use of the SparseSet data.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200919 91177308-0d34-0410-b5e6-96231b3b80d8
Add a -suppress-warnings option to bitcode linking.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200927 91177308-0d34-0410-b5e6-96231b3b80d8
X86: add costs for 64-bit vector ext/trunc & rebalance

The most important part of this is probably adding any cost at all for
operations like zext <8 x i8> to <8 x i32>. Before they were being
recorded as extremely costly (24, I believe) which made LLVM fall back
on a 4-wide vectorisation of a loop.

It also rebalances the values for sext, zext and trunc. Lacking any
other sane metric that might work across CPU microarchitectures I went
for instructions. This seems to be in reasonable accord with the rest
of the table (sitofp, ...) though no doubt at least one value is
sub-optimal for some bizarre reason.

Finally, separate AVX and AVX2 values are provided where appropriate.
The CodeGen is quite different in many cases.

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200928 91177308-0d34-0410-b5e6-96231b3b80d8
Remove const_cast for STI when parsing inline asm

In a previous commit (r199818) we added a const_cast to an existing
subtarget info instead of creating a new one so that we could reuse
it when creating the TargetAsmParser for parsing inline assembly.
This cast was necessary because we needed to reuse the existing STI
to avoid generating incorrect code when the inline asm contained
mode-switching directives (e.g. .code 16).

The root cause of the failure was that there was an implicit sharing
of the STI between the parser and the MCCodeEmitter. To fix a
different but related issue, we now explicitly pass the STI to the
MCCodeEmitter (see commits r200345-r200351).

The const_cast is no longer necessary and we can now create a fresh
STI for the inline asm parser to use.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200929 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Use immediates offsets for SMRD instructions whenever possible

There was a problem with the old pattern, so we were copying some
larger immediates into registers when we could have been encoding
them in the instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200932 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add a MUBUF load pattern for Reg+Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200933 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add a MUBUF store pattern for Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200934 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add a MUBUF store pattern for Reg+Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200935 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r200095 and r200152. It turns out when compiling with -arch armv7 -mcpu=cortex-m3, the triple would still set iOS as the OS so the hack is still needed. rdar://15984891

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200937 91177308-0d34-0410-b5e6-96231b3b80d8
Track register pressure a bit more carefully (weird corner case).

This solves a problem where a def machine operand has no uses but has
not been marked dead. In this case, the initial RP analysis was being
extra precise and determining from LiveIntervals the the register was
actually dead. This caused us to omit the register from the RP
tracker's block live out. That's all good, but the per-instruction
summary still accounted for it as a valid def. This could cause an
assertion in the tracker later when we underflow pressure.

This is from a bug report on an out-of-tree target. It is not
reproducible on well-behaved targets. I'm just making an obvious fix
without unit test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200941 91177308-0d34-0410-b5e6-96231b3b80d8