llvm-svn: 223691

There's nothing else to bother trying to shrink these.

llvm-svn: 223686

A zero sized array is zero sized and might share its address with
another global.

llvm-svn: 223684

llvm-svn: 223682

We were already lazily linking functions, but all GlobalValues can be treated
uniformly for this.

The test updates are to ensure that a given GlobalValue is still linked in.

This fixes pr21494.

llvm-svn: 223681

llvm-svn: 223680

This reverts r223624 with a small tweak, hopefully this will make stage3
equivalent.

llvm-svn: 223679

Thanks to Rafael Espindola for testing assistance.

llvm-svn: 223678

dependencies for the KS tutorials

llvm-svn: 223677

Fix a compact unwind encoding logic bug which would try to encode
more callee saved registers than it should, leading to early bail out
in the encoding logic and abusive use of DWARF frame mode unnecessarily.

Also remove no-compact-unwind.ll which was testing the wrong thing
based on this bug and move it to valid 'compact unwind' tests. Added
other few more tests too.

llvm-svn: 223676

make all doesn't build the examples and it was uniquified since
last build.

llvm-svn: 223675

llvm-svn: 223673

Introduce the ``llvm.instrprof_increment`` intrinsic and the
``-instrprof`` pass. These provide the infrastructure for writing
counters for profiling, as in clang's ``-fprofile-instr-generate``.

The implementation of the instrprof pass is ported directly out of the
CodeGenPGO classes in clang, and with the followup in clang that rips
that code out to use these new intrinsics this ends up being NFC.

Doing the instrumentation this way opens some doors in terms of
improving the counter performance. For example, this will make it
simple to experiment with alternate lowering strategies, and allows us
to try handling profiling specially in some optimizations if we want
to.

Finally, this drastically simplifies the frontend and puts all of the
lowering logic in one place.

llvm-svn: 223672

a description of how to add debug information using DWARF and
DIBuilder to the language.

Thanks to David Blaikie for his assistance with this tutorial.

llvm-svn: 223671

llvm-svn: 223670

llvm-svn: 223669

Teach ISel how to match a TZCNT/LZCNT from a conditional move if the
condition code is X86_COND_NE.
Existing tablegen patterns only allowed to match TZCNT/LZCNT from a
X86cond with condition code equal to X86_COND_E. To avoid introducing
extra rules, I added an 'ImmLeaf' definition that checks if the
condition code is COND_E or COND_NE.

llvm-svn: 223668

llvm-svn: 223667

Since the main file was empty, we can just copy the content of the Input file
into it.

llvm-svn: 223666

This is just testing the largest merge mode for comdats. No need to use
hard to read names and fancy types.

llvm-svn: 223665

llvm-svn: 223664

llvm-svn: 223663

Reviewers: vmedic

Reviewed By: vmedic

Subscribers: llvm-commits

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

llvm-svn: 223662

Before this patch, the backend sub-optimally expanded the non-constant shift
count of a v8i16 shift into a sequence of two 'movd' plus 'movzwl'.

With this patch the backend checks if the target features sse4.1. If so, then
it lets the shuffle legalizer deal with the expansion of the shift amount.

Example:
;;
define <8 x i16> @test(<8 x i16> %A, <8 x i16> %B) {
  %shamt = shufflevector <8 x i16> %B, <8 x i16> undef, <8 x i32> zeroinitializer
  %shl = shl <8 x i16> %A, %shamt
  ret <8 x i16> %shl
}
;;

Before (with -mattr=+avx):
  vmovd  %xmm1, %eax
  movzwl  %ax, %eax
  vmovd  %eax, %xmm1
  vpsllw  %xmm1, %xmm0, %xmm0
  retq

Now:
  vpxor  %xmm2, %xmm2, %xmm2
  vpblendw  $1, %xmm1, %xmm2, %xmm1
  vpsllw  %xmm1, %xmm0, %xmm0
  retq

llvm-svn: 223660

llvm-svn: 223659

llvm-svn: 223658

llvm-svn: 223657

It would crash when the function was lazy linked.

llvm-svn: 223656

Introduce install_symlink.cmake from clang/tools/driver/clang_symlink.cmake.

FIXME: Would it be generalized?
llvm-svn: 223655

* Use a range loop.
* Move simple continue checks earlier.
* clang-format.

llvm-svn: 223654

Just less code duplication.

llvm-svn: 223653

llvm-svn: 223648

X86ISelLowering.cpp has a long switch for intrinsics. I moved a part of
this long switch to the new intrinsics table in X86IntrinsicsInfo.h.
No functional changes, just code and compile time optimization.

llvm-svn: 223641

LLVM supports python 2.5, this fixes a (somewhat) recent regression.

llvm-svn: 223626

Revert a part of r223583, for now. It seems causing different emission between stage2(gcc-clang) and stage3 clang. Investigating.

llvm-svn: 223624

As a fixup to r223616, follow the convention of naming the files after
the LLVM release whose bitcode they're maintaining compatability with.

llvm-svn: 223623

r223618 including special handling of `MDNode::intersect()`: if the
first operand is a self-reference with the same operands you're trying
to return, return it instead.

Reuse that handling in `MDNode::concatenate()` in the hopes that it
fixes a polly test that seems to rely on the old behaviour [1].

[1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25167

llvm-svn: 223619

It doesn't make sense to unique self-referencing nodes.  Drop uniquing
for them.

Note that `MDNode::intersect()` occasionally returns self-referencing
nodes.  Previously these would be returned by `MDNode::get()`.  I'm not
convinced this was intended behaviour -- to me it seems it should return
a node whose only operand is the self-reference -- but I don't know much
about alias scopes so I'm preserving it for now.

This is part of PR21532.

llvm-svn: 223618

Apparently `MDNode` uniquing used to be optional.  I suppose the
configure flag must have disappeared at some point.  Change the test so
it actually tests uniquing, and remove the check for
`ENABLE_MDNODE_UNIQUING`.

llvm-svn: 223617

Add assembly and bitcode tests that I neglected to add in r223564 (IR:
Disallow complicated function-local metadata) and r223574 (IR: Disallow
function-local metadata attachments).

Found a couple of bugs:

  - The error message for function-local attachments gave the wrong line
    number -- it indicated the next token (typically on the next line)
    instead of the token that started the attachment.  Fixed.

  - Metadata arguments of the form `!{i32 0, i32 %v}` (or with the
    arguments reversed) fired an assertion in `ValueEnumerator` in LLVM
    v3.5, so I suppose this never really worked.  I suppose this was
    "fixed" by r223564.

(Thanks to dblaikie for pointing out my omission.)

Part of PR21532.

llvm-svn: 223616