Summary: This patch introduces two new iterator ranges and updates existing code to use it.  No functional change intended.

Test Plan: All tests (make check-all) still pass.

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D4481

llvm-svn: 213474

llvm-svn: 213473

llvm-svn: 213472

This probably was killed by some generic DAGCombiner
improvements in checking the TargetBooleanContents instead
of just 1.

llvm-svn: 213471

Add missing entry for eExecMessage message type to silence GCC switch coverage
warning.

llvm-svn: 213470

Hoist the compatibility macros out a level and re-use them when adding link
dependencies.  Silences a warning from CMake.

llvm-svn: 213469

llvm-svn: 213468

For ARM cores that are ARMv6T2+ but not ARMv7ve or ARMv7-r and not an updated
ARMv7-a that has the idiv extension (chips with clz but not idiv), an incorrect
jump would be calculated due to the preference to thumb instructions over ARM.

Rather than computing the target at runtime, use a jumptable instead.  This
trades a bit of storage for performance.  The overhead is 32-bytes for each of
the three routines, but avoid the calculation of the offset.

Because clz was introduced in ARMv6T2 and idiv in certain versions of ARMv7,
the non-clz, non-idiv case implies a target which does not support Thumb-2, and
thus we cannot use Thumb on those targets (as it is unlikely that the assembly
will assemble).

Take the opportunity to refactor the IT block macros into assembly.h rather than
redefining them in the TUs where they are used.

Existing tests cover the full change already, so no new tests are added.

This effectively reverts SVN r213309.

llvm-svn: 213467

llvm-svn: 213466

llvm-svn: 213465

Sure up ownership passing of the PBQPBuilder by passing unique_ptrs by value rather than lvalue reference.

Also removes an unnecessary '.release()' that should've been a std::move
anyway. (I'm on a hunt for '.release()' calls)

llvm-svn: 213464

This adds an optional parameter to the EmitSymbolValue method in MCStreamer to
permit emitting a symbol value as a section relative value.  This is to cover
the use in MCDwarf which should not really know about how to emit a section
relative value for a given target.

This addresses post-review comments from Eric Christopher in SVN r213275.

llvm-svn: 213463

target independent.

llvm-svn: 213462

llvm-svn: 213461

Seems like a bug in either GCC or clang, but I'm
not sure which is right.

llvm-svn: 213460

llvm-svn: 213459

These instructions can only take a limited input range, and return
the constant value 1 out of range. We should do range reduction to
be able to process arbitrary values. Use a FRACT instruction after
normalization to achieve this. Also add a test for constant folding
with the lowered code with unsafe-fp-math enabled.

v2: use DAG lowering instead of intrinsic, adapt test
v3: calculate constant, fold pattern into instruction definition
v4: misc style fixes, add sin-fold testcase, cosmetics

Patch by Grigori Goronzy

llvm-svn: 213458

Mostly related to missing includes and renaming of
the pass to RegionInfoPass.

llvm-svn: 213457

llvm-svn: 213456

I'm not sure if these have any effect right now.

llvm-svn: 213455

... just to find out that it didn't build.

llvm-svn: 213454

IRBuilder has CreateAligned(Load|Store) functions; use them and we don't need
to make a second call to setAlignment.

No functionality change intended.

llvm-svn: 213453

There are some kinds of metadata that are safe to propagate from the scalar
instructions to the vector instructions (fpmath and tbaa currently).

Regarding TBAA, one might worry about propagating it on if-converted loads and
stores, because the metadata might have had a control dependency on the
condition, and thus actually aliased with some other non-speculated memory
access when the condition was false. However, this would be caught by the
runtime overlap checks.

llvm-svn: 213452

Function @test3c should check that the DAGCombiner is able to fold a pair of
shuffles into a new shuffle with a permute mask of <6,7,2,3>. However, one of
the shuffles in @test3c had a wrong permute mask; this prevented the DAGCombiner
from folding the shuffles into the expected result.
Now that the shuffle mask is fixed, the backend correctly folds the two shuffles
in function @test3c into a single movhlps instruction.

llvm-svn: 213451

llvm-svn: 213450

All of the other similar functions in that part of the file look through
addrspacecast in addition to bitcast, and I see no reason why
stripAndAccumulateInBoundsConstantOffsets shouldn't do so also.

llvm-svn: 213449

llvm-svn: 213448

Make Value::isDereferenceablePointer handle offsets to pointer types with dereferenceable attributes

When we have a parameter (or call site return) with a dereferenceable
attribute, it can specify the size of an array pointed to by that parameter. If
we have a value for which we can accumulate a constant offset to such a
parameter, then we can use that offset in a direct comparison with the size
specified by the dereferenceable attribute.

This enables us to handle cases like this:

  int foo(int a[static 3]) {
    return a[2]; /* this is always dereferenceable */
  }

llvm-svn: 213447

The enum is part of ArrayType, so there is no functional change, but comparing
to ArrayType::Static for non-VLAs makes more sense.

llvm-svn: 213446

C99 array parameters can have index-type CVR qualifiers, and the TypePrinter
should print them when present (and we were not for constant-sized arrays).
Otherwise, we'd drop the restrict in:

  int foo(int a[restrict static 3]) { ... }

llvm-svn: 213445

In C99, an array parameter declarator might have the form:
  direct-declarator '[' 'static' type-qual-list[opt] assign-expr ']'

where the static keyword indicates that the caller will always provide a
pointer to the beginning of an array with at least the number of elements
specified by the assignment expression. For constant sizes, we can use the
new dereferenceable attribute to pass this information to the optimizer. For
VLAs, we don't know the size, but (for addrspace(0)) do know that the pointer
must be nonnull (and so we can use the nonnull attribute).

llvm-svn: 213444

ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.

llvm-svn: 213443

When performing a dynamic stack adjustment without optimisations, we would mark
SP as def and R4 as kill.  This occurred as part of the expansion of a
WIN__CHKSTK SDNode which indicated the proper handling of SP and R4.  The result
would be that we would double define SP as part of an operation, which is
obviously incorrect.

Furthermore, the VTList for the chain had an incorrect parameter type of i32
instead of Other.

Correct these to permit proper lowering of __builtin_alloca at -O0.

llvm-svn: 213442

FIXME: Could this be made generic?
llvm-svn: 213441

result variable and use in in "Process::LoadImage" so that,
for instance, "process load" doesn't increment the return
variable number.

llvm-svn: 213440

It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.

llvm-svn: 213439

It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.

llvm-svn: 213438

Assigns indices to try blocks. These indices will used in constructing 
tables that the mscrt function __except_handler3 reads during SEH.
Testing will occur once we actually emit the tables, in a subsequent 
patch.

llvm-svn: 213437

the error if there is one.

llvm-svn: 213436

getBasicRelocationEntry to use this rather than 'memcpy' to get the
relocation addend. Targets with non-trivial addend encodings (E.g. AArch64) can
override decodeAddend to handle immediates with interesting encodings.

No functional change.

llvm-svn: 213435