basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.

llvm-svn: 144124

llvm-svn: 144123

No functional change intended.

llvm-svn: 144122

llvm-svn: 144121

llvm-svn: 144120

type is strong by default too. // rdar://10410903

llvm-svn: 144118

The old value may still be referenced by some live-out list, and we
don't wan't to collapse those instructions twice.

This fixes the "Can only swizzle VMOVD" assertion in some armv7 SPEC
builds.

<rdar://problem/10413292>

llvm-svn: 144117

llvm-svn: 144116

llvm-svn: 144115

Analysis by Ted:
"
    if (stateZero && !stateNotZero) {

is checking to see if:

  (A)  "it is possible for the value to be zero"   (stateZero)

    AND

  (B) "it is not possible for the value to be non-zero"  (!stateNotZero)

That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check.  For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests.  So the question is whether or not such an infeasible path might not get dropped earlier?  I can't envision any right now.

Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:

    C.addTransition(stateNotZero);
"

llvm-svn: 144114

llvm-svn: 144113

llvm-svn: 144112

llvm-svn: 144111

which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.

llvm-svn: 144110

llvm-svn: 144108

LICM pass now understands invariant load metadata.  Nothing generates this yet so it will currently never get used in real tests

llvm-svn: 144107

llvm-svn: 144105

llvm-svn: 144104

Add support for trimming constants to GetDemandedBits. This fixes some funky
constant generation that occurs when stores are expanded for targets that don't
support unaligned stores natively.

llvm-svn: 144102

When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses

llvm-svn: 144100

llvm-svn: 144099

llvm-svn: 144095

llvm-svn: 144094

useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.

For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.

llvm-svn: 144089

Instead of using TempScop to find parameters, we detect them directly
on the SCEV. This allows us to remove the TempScop parameter detection
in a subsequent commit.

This fixes a bug reported by Marcello Maggioni <hayarms@gmail.com>

llvm-svn: 144087

llvm-svn: 144086

Previously we built a context that contained already all parameter dimensions
from the start. We now build a context without any parameter dimensions and
extend the context as needed. All parameter dimensions are added during final
realignment.

llvm-svn: 144085

llvm-svn: 144084

llvm-svn: 144083

implements unaligned loads and stores with assembler macro-instructions
ulw, usw, ulh, ulhu, ush, and this patch emits corresponding instructions
instead of these macros. Since each unaligned load/store is expanded
into two corresponding loads/stores where offset for second load/store is
modified by +3 (for words) or +1 (for halfwords).

Patch by Petar Jovanovic and Sasa Stankovic.

llvm-svn: 144081

PathProfiling.c: Get rid of using "inline". We may expect compiler shall optimize out "static" scope w/o "inline".

llvm-svn: 144080

llvm-svn: 144079

property attribute.

llvm-svn: 144078

llvm-svn: 144077

llvm-svn: 144076

The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.

llvm-svn: 144075

whether a given address is in an executable region of memory or
not.  I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.

I want to have this feature available for the unwinder code.  When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --

  is the current pc value in an executable region (e.g. did they
  jump to unallocated/unexecutable memory?  we know how to unwind
  from here if so.)

  Is the stack pointer or the frame pointer the correct register
  to use to find the caller's saved pc value?

Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.

llvm-svn: 144074

llvm-svn: 144073

Based on work by Dmitry Sokolov!

llvm-svn: 144072

llvm-svn: 144071