Compute mangling numbers for externally visible local variables and tags.
Change the mangler to consistently use discriminators where necessary.
Tweak the scheme we use to number decls which are not externally visible
to avoid unnecessary discriminators in common cases now that we request
them more consistently.

Fixes <rdar://problem/14204721>.

llvm-svn: 185986

attributes in migration. Specialli use of
'copy' attribute for retainable object types.

llvm-svn: 185985

llvm-svn: 185984

Patch from Matthew Sorrels

llvm-svn: 185983

Propagate the fix from r185712 to Thumb2 codegen as well. Original
commit message applies here as well:

A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and
packs them in the bottom half of "x". An arithmetic and logic shift are
only equivalent in this context if the shift amount is 16. We would be
shifting in ones into the bottom 16bits instead of zeros if "y" is
negative.

rdar://14338767

llvm-svn: 185982

llvm-svn: 185981

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

llvm-svn: 185980

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

llvm-svn: 185979

A special case list can now specify categories for specific globals,
which can be used to instruct an instrumentation pass to treat certain
functions or global variables in a specific way, such as by omitting
certain aspects of instrumentation while keeping others, or informing
the instrumentation pass that a specific uninstrumentable function
has certain semantics, thus allowing the pass to instrument callers
according to those semantics.

For example, AddressSanitizer now uses the "init" category instead of
global-init prefixes for globals whose initializers should not be
instrumented, but which in all other respects should be instrumented.

The motivating use case is DataFlowSanitizer, which will have a
number of different categories for uninstrumentable functions, such
as "functional" which specifies that a function has pure functional
semantics, or "discard" which indicates that a function's return
value should not be labelled.

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

llvm-svn: 185978

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

llvm-svn: 185977

it more unit testable, and fix memory leak in the other ctor.

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

llvm-svn: 185976

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

llvm-svn: 185975

method declaration into its implementation to
prevent a bogus warning about mismatched attributes.
then make sure the warning about missing call to super comes out
of the method implementation. // rdar://14251387

llvm-svn: 185974

llvm-svn: 185973

llvm-svn: 185972

llvm-svn: 185971

Fix PR16571, which is a bug in the code that checks that all of the types in the bundle are uniform.

llvm-svn: 185970

llvm-svn: 185968

Do not generate VLAs as complex variables any more, as they are now
correctly represented as breg+0 locations in the backend.

(Paired commit with LLVM: r185966)

rdar://problem/13658587

llvm-svn: 185967

Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old convention was that a DBG_VALUE is a register-indirect value if
the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE
is register-indirect if the first operand is a register and the second
operand is an immediate. For plain register values the combination reg,
reg is used. MachineInstrBuilder::BuildMI knows how to build the new
DBG_VALUES.

rdar://problem/13658587

llvm-svn: 185966

Thanks to Daniel Malea for helping test this patch for Linux happiness!

llvm-svn: 185965

llvm-svn: 185964

llvm-svn: 185963

Appease buildbots after r185956: just set -mcpu explicitly, as it should have been from the beginning.

llvm-svn: 185962

llvm-svn: 185961

Because integer BUILD_VECTOR operands may have a larger type than the result's
vector element type, and all operands must have the same type, when widening a
BUILD_VECTOR node by adding UNDEFs, we cannot use the vector element type, but
rather must use the type of the existing operands.

Another bug found by llvm-stress.

llvm-svn: 185960

A more complete example of the bug in PR16556 was recently provided,
showing that the previous fix was not sufficient.  The previous fix is
reverted herein.

The real problem is that ReplaceNodeResults() uses LowerFP_TO_INT as
custom lowering for FP_TO_SINT during type legalization, without
checking whether the input type is handled by that routine.
LowerFP_TO_INT requires the input to be f32 or f64, so we fail when
the input is ppcf128.

I'm leaving the test case from the initial fix (r185821) in place, and
adding the new test as another crash-only check.

llvm-svn: 185959

Attempt to appease buildbot after r185956 by explicitly turning setting -fma,-fma4 attrs (I'm assuming they're set because the bot is running on machine that has one or the other.)

llvm-svn: 185958

in-tree implementations of TargetLoweringBase::isFMAFasterThanMulAndAdd in
order to resolve the following issues with fmuladd (i.e. optional FMA)
intrinsics:

1. On X86(-64) targets, ISD::FMA nodes are formed when lowering fmuladd
intrinsics even if the subtarget does not support FMA instructions, leading
to laughably bad code generation in some situations.

2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128,
resulting in a call to a software fp128 FMA implementation.

3. On PowerPC targets, FMAs are not generated from fmuladd intrinsics on types
like v2f32, v8f32, v4f64, etc., even though they promote, split, scalarize,
etc. to types that support hardware FMAs.

The function has also been slightly renamed for consistency and to force a
merge/build conflict for any out-of-tree target implementing it. To resolve,
see comments and fixed in-tree examples.

llvm-svn: 185956

ScalarEvolution::getSignedRange uses ComputeNumSignBits from ValueTracking on
ashr instructions. ComputeNumSignBits can return zero, but this case was not
handled correctly by the code in getSignedRange which was calling:
  APInt::getSignedMinValue(BitWidth).ashr(NS - 1)
with NS = 0, resulting in an assertion failure in APInt::ashr.

Now, we just return the conservative result (as with NS == 1).

Another bug found by llvm-stress.

llvm-svn: 185955

(add nsw x, (and x, y)) isn't a power of two if x is zero, it's zero
(add nsw x, (xor x, y)) isn't a power of two if y has bits set that aren't set in x

llvm-svn: 185954

llvm-svn: 185953

llvm-svn: 185952

- re-enable tests fixed by Matt's commit this morning (addressed llvm.org/pr16567)
- disabled tests affected by new bug llvm.org/pr16575
- removed some commented out code in inferior

llvm-svn: 185951

Bill Fisher: This patch fixes a bug where regex_iterator doesn't indicate when it's restarting in the middle of a string. This bug causes /^a/ to match in the middle of the string "aaaaaaa", during iteration.

My patch uses  to communicate when  is false.

llvm-svn: 185950

When folding sub x, x (and other similar constructs), where x is a vector, the
result is a vector of zeros. After type legalization, make sure that the input
zero elements have a legal type. This type may be larger than the result's
vector element type.

This was another bug found by llvm-stress.

llvm-svn: 185949

migration. Also, fixes an old bug where older migration 
flags were not being checked for properly.

llvm-svn: 185948

llvm-svn: 185947

llvm-svn: 185946

[PowerPC] Revert r185476 and fix up TLS variant kinds

In the commit message to r185476 I wrote:

>The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD
>correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD.
>This causes some confusion with the asm parser, since VK_PPC_TLSGD
>is output as @tlsgd, which is then read back in as VK_TLSGD.
>
>To avoid this confusion, this patch removes the PowerPC-specific
>modifiers and uses the generic modifiers throughout.  (The only
>drawback is that the generic modifiers are printed in upper case
>while the usual convention on PowerPC is to use lower-case modifiers.
>But this is just a cosmetic issue.)

This was unfortunately incorrect, there is is fact another,
serious drawback to using the default VK_TLSLD/VK_TLSGD
variant kinds: using these causes ELFObjectWriter::RelocNeedsGOT
to return true, which in turn causes the ELFObjectWriter to emit
an undefined reference to _GLOBAL_OFFSET_TABLE_.

This is a problem on powerpc64, because it uses the TOC instead
of the GOT, and the linker does not provide _GLOBAL_OFFSET_TABLE_,
so the symbol remains undefined.  This means shared libraries
using TLS built with the integrated assembler are currently
broken.

While the whole RelocNeedsGOT / _GLOBAL_OFFSET_TABLE_ situation
probably ought to be properly fixed at some point, for now I'm
simply reverting the r185476 commit.  Now this in turn exposes
the breakage of handling @tlsgd/@tlsld in the asm parser that
this check-in was originally intended to fix.

To avoid this regression, I'm also adding a different fix for
this problem: while common code now parses @tlsgd as VK_TLSGD,
a special hack in the asm parser translates this code to the
platform-specific VK_PPC_TLSGD that the back-end now expects.
While this is not really pretty, it's self-contained and
shouldn't hurt anything else for now.  One the underlying
problem is fixed, this hack can be reverted again.

llvm-svn: 185945