llvm-svn: 194270

Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator.

Update the documentation style while there.

No functionnal change.

llvm-svn: 194269

ARM prologues usually look like:
    push {r7, lr}
    sub sp, sp, #4

If code size is extremely important, this can be optimised to the single
instruction:
    push {r6, r7, lr}

where we don't actually care about the contents of r6, but pushing it subtracts
4 from sp as a side effect.

This should implement such a conversion, predicated on the "minsize" function
attribute (-Oz) since I've yet to find any code it actually makes faster.

llvm-svn: 194264

[ARM] Handling for coprocessor instructions that are undefined starting from ARMv8 (Thumb encodings)

llvm-svn: 194263

llvm-svn: 194261

llvm-svn: 194259

The encoding was updated in MSA r1.07.

llvm-svn: 194255

[ARM] In ARMAsmParser, MatchCoprocessorOperandName() permitted p10 and p11 as operands for coprocessor instructions, resulting in encodings that clash with FP/NEON instruction encodings

llvm-svn: 194253

llvm-svn: 194251

No additional test was needed, Other/constant-fold-gep.ll detects this
just fine.

llvm-svn: 194221

Summary:
Consider a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0)

If we proceeded to GEP the aforementioned object by 8, would form a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8)

Note that we would go through the first array member, causing an
out-of-bounds accesses.  This is problematic because we might get fooled
if we are trying to evaluate loads using this GEP, for example, based
off of an object with a constant initializer where the array is zero.

This fixes PR17732.

Reviewers: nicholas, chandlerc, void

Reviewed By: void

CC: llvm-commits, echristo, void, aemerson

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

llvm-svn: 194220

The BlockAddress doesn't have access to the correct basic blocks until the
functions have been cloned. This causes the BlockAddress to point to the old
values. Just wait until the functions have been cloned before copying the
initializers.
PR13163

llvm-svn: 194218

llvm-svn: 194205

of being converted and this path is not relevant to anything at this time
so I have just disabled it for a few days while I'm at the LLVM conference
and don't have time to complete it or properly fix it.

llvm-svn: 194201

llvm-svn: 194153

We can change this back when NEON support is complete and ready to become
enabled by default.

llvm-svn: 194152

I don't have a standalone testcase for this, but it should allow r193676
to be reapplied.

llvm-svn: 194148

Implement gpword directive for mips, test case added. Stype changes using clang-format are also included.

llvm-svn: 194145

llvm-svn: 194144

Original patch by Chris Wailes

llvm-svn: 194143

Presence of using namespace llvm depended on several #ifdef's, and
this broke the build on mswin32.

llvm-svn: 194142

Original patch by Chris Wailes

llvm-svn: 194139

Original patch by Chris Wailes

llvm-svn: 194137

Original patch by Chris Wailes

llvm-svn: 194135

llvm-svn: 194126

llvm-svn: 194123

llvm-svn: 194118

Patch by Michele Scandale!

Rewrite of the functions used to compute the backedge taken count of a
loop on LT and GT comparisons.

I decided to split the handling of LT and GT cases becasue the trick
"a > b == -a < -b" in some cases prevents the trip count computation
due to the multiplication by -1 on the two operands of the
comparison. This issue comes from the conservative computation of
value range of SCEVs: taking the negative SCEV of an expression that
have a small positive range (e.g. [0,31]), we would have a SCEV with a
fullset as value range.

Indeed, in the new rewritten function I tried to better handle the
maximum backedge taken count computation when MAX/MIN expression are
used to handle the cases where no entry guard is found.

Some test have been modified in order to check the new value correctly
(I manually check them and reasoning on possible overflow the new
values seem correct).

I finally added a new test case related to the multiplication by -1
issue on GT comparisons.

llvm-svn: 194116

from MipsConstantIslands. 

llvm-svn: 194108

MorphNodeTo is not safe to call during DAG building. It eagerly
deletes dependent DAG nodes which invalidates the NodeMap. We could
expose a safe interface for morphing nodes, but I don't think it's
worth it. Just create a new MachineNode and replaceAllUsesWith.

My understaning of the SD design has been that we want to support
early target opcode selection. That isn't very well supported, but
generally works. It seems reasonable to rely on this feature even if
it isn't widely used.

llvm-svn: 194102

we don't have such an operand.
Suprisingly enough, this is never actually accounted for in the 
ARM version when determining offset ranges. In both places there is the
comment:
-    // FIXME: Make use full range of soimm values.
(soimm = shift operand immediate).

llvm-svn: 194101

alignment will be handled differently than in ARM constant islands.

llvm-svn: 194096

Cortex-M0 supports these 32-bit instructions despite being Thumb1 only
(mostly). We knew about that but not that the aliases without the default "sy"
operand were also permitted.

llvm-svn: 194094

They just propagate out the bitcode reader error, so we don't need a new enum.

llvm-svn: 194091

llvm-svn: 194085

llvm-svn: 194084

[objc-arc] Convert the one directional retain/release relation assert to a conditional check + fail.

Due to the previously added overflow checks, we can have a retain/release
relation that is one directional. This occurs specifically when we run into an
additive overflow causing us to drop state in only one direction. If that
occurs, we should bail and not optimize that retain/release instead of
asserting.

Apologies for the size of the testcase. It is necessary to cause the additive
cfg overflow to trigger.

rdar://15377890

llvm-svn: 194083

llvm-svn: 194077

command regarding the porting from the ARM version (was an old comment).

llvm-svn: 194066

llvm-svn: 194062