Summary:
`hasNoAliasAttr` is buggy: it checks to see if the called function has
a `noalias` attribute, which is incorrect since functions are not even
allowed to have the `noalias` attribute.  The comment on its only
caller, `llvm::isNoAliasFn`, makes it pretty clear that the intention
to do the `noalias` check on the return value, and not the callee.

Unfortunately I couldn't find a way to test this upstream -- fixing
this does not change the observable behavior of any of the passes that
use this.  This is not very surprising, since `noalias` does not tell
anything about the contents of the allocated memory (so, e.g., you
still cannot fold loads).  I'll be happy to be proven wrong though.

Reviewers: chandlerc, reames

Subscribers: mcrosier, llvm-commits

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

llvm-svn: 260298

Most constants defined in llvm::dwarf namespace start with "DW_".
We don't have to worry about name conflicts.

llvm-svn: 260297

While trying to track down what appears to be a LoopVectorizer bug, I noticed that we had no validation of the correctness of calls emitted to @llvm.masked.load and @llvm.masked.store.  This meant malformed IR was showing up much much later than it should.  Hopefully, having Verifier rules in place will make this easier to isolate.

llvm-svn: 260296

I reinvented this functionality in http://reviews.llvm.org/D16828 because it was
hidden away as a static function. The changes in x86 are not based on a complete
audit. I suspect there are other possible uses there, and there are almost certainly
more potential users in other targets.

llvm-svn: 260295

This basically reverts commit r260073 because it is found that
augmentation strings don't always start with "zR". It is reported
as https://llvm.org/bugs/show_bug.cgi?id=26541.

llvm-svn: 260294

But now it follows the llvm style, uses an early return and doesn't
include a file named 1.o.

llvm-svn: 260293

llvm-svn: 260292

These were supposed to have been removed in a previous patch,
but I missed them.

llvm-svn: 260291

All existing usages were ported over to the common decorators.

llvm-svn: 260290

Ported everything over to using expectedFailureAll.

llvm-svn: 260289

All decorator invocations are updated to use the generic
expectedFailureAll and skipIf decorators.

llvm-svn: 260288

Functions start with a lower case, variables with an upper case.

llvm-svn: 260287

llvm-svn: 260286

This reverts commit r259578.

There are enough issues with this small patch that it is better to
revert and then commit a fixed version (will be committed shortly).

llvm-svn: 260285

If we set the DYLD_INSERT_LIBRARIES environment variable when launching debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't pass this environment variable on to any child processes.

llvm-svn: 260284

llvm-svn: 260283

Don't enable -flimit-debug-info by default for the LLDB Xcode builds. This was put in back in 2011 when -flimit-debug-info did a lot less than it does now. With llvm-dsymutil doing ODR type unique stuff we still have reasonably sized dSYM files.

llvm-svn: 260282

This test fails in the ninja-x64-msvc-RA-centos6 builder, so the
UNSUPPORTED: system-windows condition is insufficient.  Removing it
for now; I will investigate how this can be fixed later.

llvm-svn: 260281

llvm-svn: 260280

We introduced gc.relocates of vector-of-pointer types a couple of weeks back.  Somehow, I missed updating the InstCombine rule to account for this.  If we hit this code path with a vector-of-pointers gc.relocate, we'd crash on a cast<PointerType>.

I also took the chance to do a bit of code style cleanup.

llvm-svn: 260279

that type from the global scope.

Patch by Sterling Augustine, derived (with permission) from code from Cling by
Vassil Vassilev and Philippe Canal.

llvm-svn: 260278

what it's actually trying to do.

llvm-svn: 260277

llvm-svn: 260276

Summary:
Fix case where a pre-inc/dec load/store would not be formed if the
add/sub that forms the inc/dec part of the operation was the first
instruction in the block being examined.

Reviewers: mcrosier, jmolloy, t.p.northover, junbuml

Subscribers: aemerson, rengolin, mcrosier, llvm-commits

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

llvm-svn: 260275

llvm-svn: 260274

llvm-svn: 260273

llvm-svn: 260272

The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers.  On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.

rdar://problem/24572729

llvm-svn: 260271

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

llvm-svn: 260270

llvm-svn: 260269

This is the third time it has crossed the 2^16 section limit. We've
already spent time optimizing this file to reduce template
instantiations, and it's not clear that there is anymore low hanging
fruit.

llvm-svn: 260267

llvm-svn: 260266

This builds on the support being added to LLVM to import and export
registries from DLLs.  This will allow us to pick up the registry
entries added in the DLL's copy of FrontendPluginRegistry.

This will allow us to use plugins on Windows using:
$ clang-cl -Xclang -load -Xclang plugin.dll \
           -Xclang -add-plugin -Xclang foo

llvm-svn: 260265

llvm-svn: 260264

Summary:
This patch adds Windows support for a few of the llvm-config commands,
including cflags, ldflags, libs, and system-libs.

Currently llvm-config is untested, so this patch adds tests for the
commands that it fixes as well.

Reviewers: rnk

Subscribers: llvm-commits

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

llvm-svn: 260263

Reviewers: rnk

Subscribers: llvm-commits

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

llvm-svn: 260262

On Windows, the DLL containing the registry will get its own global head
and tail variables, so the entries registered in the DLL will be
invisible to the consumer.

In order to solve this, we need to export a getter function from the
plugin DLL per registry and copy over the data inside it.  This patch
adds support for this.  This will be used to support clang plugins on
Windows.

llvm-svn: 260261

llvm-svn: 260260

llvm-svn: 260259

llvm-svn: 260258