llvm-svn: 161529

I don't have a win32 system to test, so hopefully I got them all fixed here.

llvm-svn: 161519

- The defines are in stddint.h, which is #include'd already.
- The block wasn't used anyway, since it was _OpenBSD_, and not __OpenBSD__

Patch by David Hill!

llvm-svn: 161515

llvm-svn: 161513

Thanks, Andy!

llvm-svn: 161507

llvm-svn: 161505

This patch allows us to use cmake to specify a cross compiler for Hexagon.

In particular, the patch adds a missing case for the target Hexagon in
cmake/config-ix.cmake, and it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time. Here is the command line that I have used to test
my patches:

$ cmake -G Ninja -D BUILD_SHARED_LIBS:BOOL=ON -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu -D LLVM_ENABLE_PIC:BOOL=OFF ..
$ ninja check

llvm-svn: 161504

Committing it first as it makes the "real" patch a lot easier to read.

llvm-svn: 161491

llvm-svn: 161489

Patch by kai@redstar.de !

llvm-svn: 161487

llvm-svn: 161479

llvm-svn: 161478

There are situations where inline ASM may want to change the section -- for
instance, to create a variable in the .data section. However, it cannot do this
without (potentially) restoring to the wrong section. E.g.:

  asm volatile (".section __DATA, __data\n\t"
                ".globl _fnord\n\t"
                "_fnord: .quad 1f\n\t"
                ".text\n\t"
                "1:" :::);

This may be wrong if this is inlined into a function that has a "section"
attribute. The user should use `.pushsection' and `.popsection' here instead.

The addition of `.previous' is added for completeness.
<rdar://problem/12048387>

llvm-svn: 161477

This replaces an existing subtarget hook on ARM and allows standard
CodeGen passes to potentially use the property.

llvm-svn: 161471

llvm-svn: 161470

llvm-svn: 161469

sure we account for that correctly in DeadStoreElimination.  Fixes a regression
from r158919.  PR13547.

llvm-svn: 161468

It caused an assertion failure when compiling consumer-typeset.

llvm-svn: 161463

We perform the following:
1> Use SUB instead of CMP for i8,i16,i32 and i64 in ISel lowering.
2> Modify MachineCSE to correctly handle implicit defs.
3> Convert SUB back to CMP if possible at peephole.

Removed pattern matching of (a>b) ? (a-b):0 and like, since they are handled
by peephole now.

rdar://11873276

llvm-svn: 161462

We can't rematerialize a PIC base after register allocation anyway, and
scanning physreg use-def chains is very expensive in a function with
many calls.

<rdar://problem/12047515>

llvm-svn: 161461

The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.

llvm-svn: 161460

multiple scalar promotions on a single loop. This also has the effect of
preserving the order of stores sunk out of loops, which is aesthetically
pleasing, and it happens to fix the testcase in PR13542, though it doesn't
fix the underlying problem.

llvm-svn: 161459

llvm-svn: 161454

This adds support for TargetIndex operands during isel. The meaning of
these (index, offset, flags) operands is entirely defined by the target.

llvm-svn: 161453

An unsigned value converted to floating-point will always be greater than
a negative constant.  Unfortunately InstCombine reversed the check so that
unsigned values were being optimized to always be greater than all positive
floating-point constants.  <rdar://problem/12029145>

llvm-svn: 161452

do so when the high bits are known zero. This caused a subtle miscompilation.

rdar://12027825 

llvm-svn: 161451

character arrays. This is in line with what GCC does.
<rdar://problem/10529227>

llvm-svn: 161446

A target index operand looks a lot like a constant pool reference, but
it is completely target-defined. It contains the 8-bit TargetFlags, a
32-bit index, and a 64-bit offset. It is preserved by all code generator
passes.

TargetIndex operands can be used to carry target-specific information in
cases where immediate operands won't suffice.

llvm-svn: 161441

llvm-svn: 161438

llvm-svn: 161437

Compare the critical paths of the two traces through an if-conversion
candidate. If the difference is larger than the branch brediction
penalty, reject the if-conversion. If would never pay.

llvm-svn: 161433

llvm-svn: 161430

a use or a BB, but it is inline in the handling of the invoke instruction.

This patch refactors it so that it can be used in other cases. For example, in

define i32 @f(i32 %x) {
bb0:
  %cmp = icmp eq i32 %x, 0
  br i1 %cmp, label %bb2, label %bb1
bb1:
  br label %bb2
bb2:
  %cond = phi i32 [ %x, %bb0 ], [ 0, %bb1 ]
  %foo = add i32 %cond, %x
  ret i32 %foo
}

GVN should be able to replace %x with 0 in any use that is dominated by the
true edge out of bb0. In the above example the only such use is the one in
the phi.

llvm-svn: 161429

Thanks to Alex Rosenberg for the suggestion.

llvm-svn: 161428

and "instruction address -> file/line" lookup.

Instead of plain collection of rows, debug line table for compilation unit is now
treated as the number of row ranges, describing sequences (series of contiguous machine
instructions). The sequences are not always listed in the order of increasing
address, so previously used std::lower_bound() sometimes produced wrong results.
Now the instruction address lookup consists of two stages: finding the correct
sequence, and searching for address in range of rows for this sequence.

llvm-svn: 161414

We give a bonus for every argument because the argument setup is not needed
anymore when the function is inlined. With this patch we interpret byval
arguments as a compact representation of many arguments. The byval argument
setup is implemented in the backend as an inline memcpy, so to model the
cost as accurately as possible we take the number of pointer-sized elements
in the byval argument and give a bonus of 2 instructions for every one of
those. The bonus is capped at 8 elements, which is the number of stores
at which the x86 backend switches from an expanded inline memcpy to a real
memcpy. It would be better to use the real memcpy threshold from the backend,
but it's not available via TargetData.

This change brings the performance of c-ray in line with gcc 4.7. The included
test case tries to reproduce the c-ray problem to catch regressions for this
benchmark early, its performance is dominated by the inline decision of a
specific call.

This only has a small impact on most code, more on x86 and arm than on x86_64
due to the way the ABI works. When building LLVM for x86 it gives a small
inline cost boost to virtually any function using StringRef or STL allocators,
but only a 0.01% increase in overall binary size. The size of gcc compiled by
clang actually shrunk by a couple bytes with this patch applied, but not
significantly.

llvm-svn: 161413

instsimplify+inline strategy.

The crux of the problem is that instsimplify was reasonably relying on
an invariant that is true within any single function, but is no longer
true mid-inline the way we use it. This invariant is that an argument
pointer != a local (alloca) pointer.

The fix is really light weight though, and allows instsimplify to be
resiliant to these situations: when checking the relation ships to
function arguments, ensure that the argumets come from the same
function. If they come from different functions, then none of these
assumptions hold. All credit to Benjamin Kramer for coming up with this
clever solution to the problem.

llvm-svn: 161410

Previously, MBP essentially aligned every branch target it could. This
bloats code quite a bit, especially non-looping code which has no real
reason to prefer aligned branch targets so heavily.

As Andy said in review, it's still a bit odd to do this without a real
cost model, but this at least has much more plausible heuristics.

Fixes PR13265.

llvm-svn: 161409

If the result of a common subexpression is used at all uses of the candidate
expression, CSE should not increase the live range of the common subexpression.

rdar://11393714 and rdar://11819721

llvm-svn: 161396

--- Reverse-merging r161371 into '.':
U    include/llvm/Target/TargetData.h
U    lib/Target/TargetData.cpp

llvm-svn: 161394