PR14972: SROA vs. GVN exposed a really bad bug in SROA.

The fundamental problem is that SROA didn't allow for overly wide loads
where the bits past the end of the alloca were masked away and the load
was sufficiently aligned to ensure there is no risk of page fault, or
other trapping behavior. With such widened loads, SROA would delete the
load entirely rather than clamping it to the size of the alloca in order
to allow mem2reg to fire. This was exposed by a test case that neatly
arranged for GVN to run first, widening certain loads, followed by an
inline step, and then SROA which miscompiles the code. However, I see no
reason why this hasn't been plaguing us in other contexts. It seems
deeply broken.

Diagnosing all of the above took all of 10 minutes of debugging. The
really annoying aspect is that fixing this completely breaks the pass.
;] There was an implicit reliance on the fact that no loads or stores
extended past the alloca once we decided to rewrite them in the final
stage of SROA. This was used to encode information about whether the
loads and stores had been split across multiple partitions of the
original alloca. That required threading explicit tracking of whether
a *use* of a partition is split across multiple partitions.

Once that was done, another problem arose: we allowed splitting of
integer loads and stores iff they were loads and stores to the entire
alloca. This is a really arbitrary limitation, and splitting at least
some integer loads and stores is crucial to maximize promotion
opportunities. My first attempt was to start removing the restriction
entirely, but currently that does Very Bad Things by causing *many*
common alloca patterns to be fully decomposed into i8 operations and
lots of or-ing together to produce larger integers on demand. The code
bloat is terrifying. That is still the right end-goal, but substantial
work must be done to either merge partitions or ensure that small i8
values are eagerly merged in some other pass. Sadly, figuring all this
out took essentially all the time and effort here.

So the end result is that we allow splitting only when the load or store
at least covers the alloca. That ensures widened loads and stores don't
hurt SROA, and that we don't rampantly decompose operations more than we
have previously.

All of this was already fairly well tested, and so I've just updated the
tests to cover the wide load behavior. I can add a test that crafts the
pass ordering magic which caused the original PR, but that seems really
brittle and to provide little benefit. The fundamental problem is that
widened loads should Just Work.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177055 91177308-0d34-0410-b5e6-96231b3b80d8
[ASan] emit instrumentation for initialization order checking by default

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177063 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Factorize code handling Const Read Port limitation

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177078 91177308-0d34-0410-b5e6-96231b3b80d8
Test that we emit a DW_AT_location for self captured by a block.
This is the backend part of a CFE test with the same name.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177087 91177308-0d34-0410-b5e6-96231b3b80d8
Perform factorization as a last resort of unsafe fadd/fsub simplification.

Rules include:
  1)1 x*y +/- x*z => x*(y +/- z) 
    (the order of operands dosen't matter)

  2) y/x +/- z/x => (y +/- z)/x 

 The transformation is disabled if the new add/sub expr "y +/- z" is a 
denormal/naz/inifinity.

rdar://12911472


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177088 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Define two subclasses of MipsDAGToDAGISel. Mips16DAGToDAGISel is for
mips16 and MipsSEDAGToDAGISel is for mips32/64. 

No functionality changes.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177089 91177308-0d34-0410-b5e6-96231b3b80d8
Add header file MipsISelDAGToDAG.h.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177090 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Rename functions and variables to start with proper case.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177092 91177308-0d34-0410-b5e6-96231b3b80d8
Add a comment about overlapping PPC frame offsets

I don't think that it is otherwise clear how the overlapping offsets
are processed into distinct spill slots. Comment that this is done
in processFunctionBeforeFrameFinalized.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177094 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Define function MipsSEDAGToDAGISel::selectAddESubE.

No intended functionality changes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177095 91177308-0d34-0410-b5e6-96231b3b80d8
Add back lines which were accidentally deleted in CMakeLists.txt.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177096 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Invert case when we use a vector cmp value to query select cost

We generate a select with a vectorized condition argument when the condition is
NOT loop invariant. Not the other way around.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177098 91177308-0d34-0410-b5e6-96231b3b80d8
Android uses cacheflush(long start, long end, long flags) for MIPS.

Patch by Stephen Hines.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177101 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing asserts flag to test - it uses debug flags

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177102 91177308-0d34-0410-b5e6-96231b3b80d8
Hexagon: Removed asserts regarding alignment and offset.
We are warning the user about the alignment, so we should not assert.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177103 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Fix filename in comment and delete unnecessary lines of code.

No functionality changes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177104 91177308-0d34-0410-b5e6-96231b3b80d8
ARM cost model: Increase cost of some vector selects we do terrible on

By terrible I mean we store/load from the stack.

This matters on PAQp8 in _Z5trainPsS_ii (which is inlined into Mixer::update)
where we decide to vectorize a loop with a VF of 8 resulting in a 25%
degradation on a cortex-a8.

LV: Found an estimated cost of 2 for VF 8 For instruction:   icmp slt i32
LV: Found an estimated cost of 2 for VF 8 For instruction:   select i1, i32, i32

The bug that tracks the CodeGen part is PR14868.

radar://13403975

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177105 91177308-0d34-0410-b5e6-96231b3b80d8
Not all PPC functions with a frame pointer need a RS spill slot

We used to add a spill slot for the register scavenger whenever the function
has a frame pointer. This is unnecessarily conservative: We may need the spill
slot for dynamic stack allocations, and functions with dynamic stack
allocations always have a FP, but we might also have a FP for other reasons
(such as the user explicitly disabling frame-pointer elimination), and we don't
necessarily need a spill slot for those functions.

The structsinregs test needed adjustment because it disables FP elimination.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177106 91177308-0d34-0410-b5e6-96231b3b80d8
Use frame-index scavenging for PPC register spilling

Make requiresFrameIndexScavenging return true, and create virtual registers in
the spilling code instead of using the register scavenger directly. This makes
the target-level code simpler, and importantly, delays the scavenging until
after callee-saved register processing (which will be important for later
changes).

Also cleans up trackLivenessAfterRegAlloc (makes it inline in the header with
the other related functions). This makes it clear that it always returns true.

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177107 91177308-0d34-0410-b5e6-96231b3b80d8
Provide the register scavenger to processFunctionBeforeFrameFinalized

Add the current PEI register scavenger as a parameter to the
processFunctionBeforeFrameFinalized callback.

This change is necessary in order to allow the PowerPC target code to
set the register scavenger frame index after the save-area offset
adjustments performed by processFunctionBeforeFrameFinalized. Only
after these adjustments have been made is it possible to estimate
the size of the stack frame.

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