For COFF only: dwarf debug info output a label reference as a section relative item only when it's one of dw_from strp, sec_offset, ref_addr or op_call_ref instead of going by size.

llvm-svn: 188296

Before this, collectAttributes() was operating on a local object.

llvm-svn: 188254

Summary:
We need to do two things:

- Initialize BSSSection in MCObjectFileInfo::InitCOFFMCObjectFileInfo
- Teach TargetLoweringObjectFileCOFF::SelectSectionForGlobal what to do
  with it

This fixes PR16861.

Reviewers: rnk

Reviewed By: rnk

CC: llvm-commits

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

llvm-svn: 188244

CUs.

Currently only hashes the name of CUs and the names of any children,
but it's an obvious first step to show the framework. The testcase
should continue to be correct, however, as it's an empty TU.

llvm-svn: 188243

llvm-svn: 188233

llvm-svn: 188232

llvm-svn: 188203

llvm-svn: 188202

llvm-svn: 188201

has been finalized except for sizes and offsets. Update test accordingly.

llvm-svn: 188199

We support this libcall on all platforms except for OpenBSD (See
lib/Codegen/StackProtector.cpp).

llvm-svn: 188193

For now this is restricted to fixed-length comparisons with a length
in the range [1, 256], as for memcpy() and MVC.

llvm-svn: 188163

If the tail-callee and caller give the same bits via the same signext/zeroext
attribute then a tail-call should be allowed, since the extension has already
been done by the callee.

llvm-svn: 188159

[stackprotector] Simplify SP Pass so that we emit different fail basic blocks for each fail condition.

This patch decouples the stack protector pass so that we can support stack
protector implementations that do not use the IR level generated stack protector
fail basic block.

No codesize increase is caused by this change since the MI level tail merge pass
properly merges together the fail condition blocks (see the updated test).

llvm-svn: 188105

llvm-svn: 188074

Change asserts at the top of getVectorShuffle to check that LHS and RHS have the same type as the result.

Previously the asserts were only checking that RHS and LHS were the same type and had the same element type as the result. All downstream code for ISD::VECTOR_SHUFFLE requires the types to be the same.

Also removed one unnecessary check of matched element counts that was present in the code.

llvm-svn: 188051

For most libm ISD nodes, TargetLoweringBase::initActions sets the default
scalar-type action to Expand, and leaves the vector-type action default as
Legal. This is not appropriate for the new ISD::FROUND node (which no backend
but PowerPC handles explicitly).

Fixes PR16842.

llvm-svn: 188048

llvm-svn: 188030

No functional change intended.

llvm-svn: 188028

This reverts commit r187939. It broke an O0 build of a spec benchmark.

llvm-svn: 188012

be void and therefore not have a type entry. Only add the type if
it is non-void and provide a testcase.

llvm-svn: 187966

Remove AllUndef check from one of the loops in getVectorShuffle. It was already handled by the 'AllLHS && AllRHS' check after the previous loop.

llvm-svn: 187965

llvm-svn: 187964

the type exists.

Fix up cases where we weren't checking for optional types and add
an assert to addType to make sure we catch this in the future.

Fix up a testcase that was using the tag for DW_TAG_array_type
when it meant DW_TAG_enumeration_type.

llvm-svn: 187963

llvm-svn: 187962

llvm-svn: 187961

This reverts commit r77814.

We were sticking global constants in the .data section instead of in the
.rdata section when emitting for COFF.

This fixes PR16831.

llvm-svn: 187956

llvm-svn: 187954

llvm-svn: 187953

Original commit message:

Stop emitting weak symbols into the "coal" sections.

The Mach-O linker has been able to support the weak-def bit on any symbol for
quite a while now. The compiler however continued to place these symbols into a
"coal" section, which required the linker to map them back to the base section
name.

Replace the sections like this:

  __TEXT/__textcoal_nt   instead use  __TEXT/__text
  __TEXT/__const_coal    instead use  __TEXT/__const
  __DATA/__datacoal_nt   instead use  __DATA/__data

<rdar://problem/14265330>

llvm-svn: 187939

All libm floating-point rounding functions, except for round(), had their own
ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm
adding ISD::FROUND so that round() can be custom lowered as well.

For the most part, this is straightforward. I've added an intrinsic
and a matching ISD node just like those for nearbyint() and friends. The
SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed
fround).

This will be used by the PowerPC backend in a follow-up commit.

llvm-svn: 187926

.tbss section for zerofill thread locals. Make sure we do this
before emitting the zerofills.

Fixes PR15972.

llvm-svn: 187913

llvm-svn: 187895

llvm-svn: 187872

Use it when we're looking for a string in particular. Update comments
as well.

llvm-svn: 187844

No functional change.

llvm-svn: 187843

Patch by Marc Jessome!

llvm-svn: 187825

This change came about primarily because of two issues in the existing code.
Niether of:

define i64 @test1(i64 %val) {
  %in = trunc i64 %val to i32
  tail call i32 @ret32(i32 returned %in)
  ret i64 %val
}

define i64 @test2(i64 %val) {
  tail call i32 @ret32(i32 returned undef)
  ret i32 42
}

should be tail calls, and the function sameNoopInput is responsible. The main
problem is that it is completely symmetric in the "tail call" and "ret" value,
but in reality different things are allowed on each side.

For these cases:
1. Any truncation should lead to a larger value being generated by "tail call"
   than needed by "ret".
2. Undef should only be allowed as a source for ret, not as a result of the
   call.

Along the way I noticed that a mismatch between what this function treats as a
valid truncation and what the backends see can lead to invalid calls as well
(see x86-32 test case).

This patch refactors the code so that instead of being based primarily on
values which it recurses into when necessary, it starts by inspecting the type
and considers each fundamental slot that the backend will see in turn. For
example, given a pathological function that returned {{}, {{}, i32, {}}, i32}
we would consider each "real" i32 in turn, and ask if it passes through
unchanged. This is much closer to what the backend sees as a result of
ComputeValueVTs.

Aside from the bug fixes, this eliminates the recursion that's going on and, I
believe, makes the bulk of the code significantly easier to understand. The
trade-off is the nasty iterators needed to find the real types inside a
returned value.

llvm-svn: 187787

llvm-svn: 187778

llvm-svn: 187752