llvm-svn: 194314

llvm-svn: 194313

llvm-svn: 194311

formal arguments on the stack and stores created afterwards. We need this to
ensure tail call optimized function calls do not write over the argument area
of the stack before it is read out.
 

llvm-svn: 194309

llvm-svn: 194308

This patch moves the jump address materialization inside the noop slide. This
enables patching of the materialization itself or its complete removal. This
patch also adds the ability to define scratch registers that can be used safely
by the code called from the patchpoint intrinsic. At least one scratch register
is required, because that one is used for the materialization of the jump
address. This patch depends on D2009.

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

Reviewed by Andy

llvm-svn: 194306

This would cause internal symbols that are only referenced by global initializers to be removed.

This reverts commit 194219.

llvm-svn: 194304

This reverts commit 194219.

llvm-svn: 194303

The new graph structure replaces the node and edge linked lists with vectors.
Free lists (well, free vectors) are used for fast insertion/deletion.

The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
the PBQP solver destructively consumes input graphs while computing a solution,
forcing the graph to be fully reconstructed for each round of PBQP. This
imposes a high cost on large functions, which often require several rounds of
solving/spilling to find a final register allocation. If we can cheaply clone
the PBQP graph and incrementally update it between rounds then hopefully we can
reduce this cost. Further, once we begin pooling matrix/vector values (future
work), we can cache some PBQP solver metadata and share it between cloned
graphs, allowing the PBQP solver to re-use some of the computation done in
earlier rounds.

For now this is just a data structure update. The allocator and solver still
use the graph the same way as before, fully reconstructing it between each
round. I expect no material change from this update, although it may change
the iteration order of the nodes, causing ties in the solver to break in
different directions, and this could perturb the generated allocations
(hopefully in a completely benign way).

Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
to work on this, and for a lot of discussion and many useful PBQP test cases.

llvm-svn: 194300

The idea of the AnyReg Calling Convention is to provide the call arguments in
registers, but not to force them to be placed in a paticular order into a
specified set of registers. Instead it is up tp the register allocator to assign
any register as it sees fit. The same applies to the return value (if
applicable).

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

Reviewed by Andy

llvm-svn: 194293

increase the accuracy of register pressure computation in the presence of dead definitions by using live intervals, if available, to identify dead definitions and proceed accordingly.

llvm-svn: 194286

On darwin, when trying to create compact unwind info, a .cfi_cfa_def
directive would case an llvm_unreachable() to be hit. Back off when we
see this directive and generate the regular DWARF style eh_frame.

rdar://15406518

llvm-svn: 194285

llvm-svn: 194284

Thanks to Eric Christopher for the tips on the appropriate way to do this.

llvm-svn: 194282

LoopUnswitch's code simplification routine has logic to convert conditional
branches into unconditional branches, after unswitching makes the condition
constant, and then remove any blocks that renders dead. Unfortunately, this
code is dead, currently broken, and furthermore, has never been alive (at least
as far back at 2006).

No functionality change intended.

llvm-svn: 194277

Temporarily revert my previous commit until I understand why it breaks 3 target tests.

llvm-svn: 194272

isPhysRegUsed if the unwind information is required.
Indeed, the runtime may need a correct stack to be able to unwind the call.

llvm-svn: 194271

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

Useful for tri-state maps: true, false, and "no data yet".

llvm-svn: 194266

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: 194262

llvm-svn: 194261

llvm-svn: 194260

llvm-svn: 194259

llvm-svn: 194258

Linux cannot open directories with open(2), although cygwin and *bsd can.

Motivation: The test, Object/directory.ll, had been failing with --target=cygwin on Linux. XFAIL was improper for host issues.
llvm-svn: 194257

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

llvm-svn: 194219

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

llvm-svn: 194203

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

after the 3.4 release to the release notes. See the *lengthy* llvmdev
and cfe-dev threads on this subject. There will be more emails,
discussion and announcements, but I want to make noise in as many places
as I can to get everyone's concerns voiced and understood.

llvm-svn: 194183

llvm-svn: 194153