commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.

Original log:

    ConstantArray::get() (for strings) is going away, use
    ConstantDataArray::getString instead.

    Many instances of ConstantArray::get() could be moved to
    use more efficient ConstantDataArray methods that avoid a ton
    of intermediate Constant*'s for each element (e.g.
    GetConstantArrayFromStringLiteral).  I don't plan on doing this
    in the short-term though.

llvm-svn: 149477

instead of the entire class definition.

llvm-svn: 149474

Patch by Niels Grewe!

llvm-svn: 149401

llvm-svn: 149377

ConstantDataArray::getString instead.

Many instances of ConstantArray::get() could be moved to 
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g. 
GetConstantArrayFromStringLiteral).  I don't plan on doing this
in the short-term though.

llvm-svn: 149363

as well as ConstantArray.

llvm-svn: 149347

argument. twik to support the test case.
// rdar://10444476

llvm-svn: 149298

consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
In this patch, the null path releases consumed argument.
// rdar://10444474

llvm-svn: 149279

llvm-svn: 149237

Remove custom handling for cmpsd/cmpss/cmppd/cmpps builtins. The builtins are now in IntrinsicsX86.td.

llvm-svn: 149235

Cleanup 3dnow builtin handling. Most of them were already handled by LLVM connecting intrinsics and builtins in IntrinsicsX86.td.

llvm-svn: 149233

recently.  This also conveniently gets clang ready for a change about to
land in mainline.

llvm-svn: 149225

llvm-svn: 149205

kill the retain from the return site.

This has the workaround nature.  It's badness all around.

llvm-svn: 149193

in the presence of straight-line cleanups.  This is a simple but
important case, particularly for ARC.

llvm-svn: 149190

consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474

llvm-svn: 149184

There is really no reason to have these only available on x86. It's
just __builtin_c[tl]z for shorts.

Modernize the test while at it.

llvm-svn: 149183

llvm-svn: 149104

ARM supports clz and ctz directly and both operations have well-defined
results for zero.  There is no disadvantage in performance to using the
defined-at-zero versions of llvm.ctlz/cttz intrinsics.  We're running into
ARM-specific code written with the assumption that __builtin_clz(0) == 32,
even though that value is technically undefined.  The code is failing now
because of llvm optimizations that are taking advantage of the undef
behavior (specifically svn r147255).  There's nothing wrong with that
optimization on x86 where any incorrect assumptions about __builtin_clz(0)
will quickly be exposed.  For ARM, though, optimizations based on that undef
behavior are likely to cause subtle bugs.  Other targets with defined-at-zero
clz/ctz support may want to override the default behavior as well.

llvm-svn: 149086

llvm-svn: 149051

the gdb testsuite complains too much about the ordering of items printed,
even if the offsets in the debug info are correct.

This reverts commit 027cb30af828f07750f9185782822297a5c57231.

llvm-svn: 149049

llvm-svn: 149047

around, in the process cleaning up the various gcc/msvc compiler
workarounds.

llvm-svn: 149036

llvm-svn: 149015

llvm-svn: 149013

llvm-svn: 149012

Add some ABI tweaks for i386-pc-win32 triple so that we return structs in an MSVC-compatible way.  Patch by Joe Groff.

llvm-svn: 148992

llvm-svn: 148982

llvm-svn: 148943

"use the new ConstantVector::getSplat method where it makes sense."

Also simplify a bunch of code to use the Builder->getInt32 instead
of doing it the hard and ugly way.  Much more progress could be made
here, but I don't plan to do it.

llvm-svn: 148926

llvm-svn: 148923

Original log:
 use the new ConstantVector::getSplat method where it makes sense.

llvm-svn: 148907

llvm-svn: 148904

llvm-svn: 148903

llvm-svn: 148902

address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.

When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).

With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.

llvm-svn: 148842

type of pointers. 

llvm-svn: 148753

llvm-svn: 148744

X86 backend in LLVM.

llvm-svn: 148689

Add an assertion that our use-marking actually covers all uses of a variable.  The assertion doesn't cover quite as much as it should, but it's a good start, at least.

llvm-svn: 148625