Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

Fix-up for r165718, should get the buildbots back online.

llvm-svn: 165723

with x86/ARM architecture

llvm-svn: 165722

Not all instructions define a virtual register in their first operand.
Specifically, INLINEASM has a different format.

<rdar://problem/12472811>

llvm-svn: 165721

Grosser.

llvm-svn: 165720

This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.

<rdar://problem/12437490>

llvm-svn: 165719

Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.

This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.

<rdar://problem/12407765>

llvm-svn: 165718

The ASTUnit needs to initialize an ASTWriter at the beginning of
parsing to fully handle serialization of a translation unit that
imports modules. Do this by introducing an option to enable it, which
corresponds to CXTranslationUnit_ForSerialization on the C API side.

llvm-svn: 165717

Currently, Objective-C does not support class properties, even though it
allows calling class methods with dot syntax.

No intended functionality change; purely optimization.

llvm-svn: 165716

and Native Client

llvm-svn: 165715

For function calls on the 64-bit PowerPC SVR4 target, each parameter
is mapped to as many doublewords in the parameter save area as
necessary to hold the parameter.  The first 13 non-varargs
floating-point values are passed in registers; any additional
floating-point parameters are passed in the parameter save area.  A
single-precision floating-point parameter (32 bits) must be mapped to
the second (rightmost, low-order) word of its assigned doubleword
slot.

Currently LLVM violates this ABI requirement by mapping such a
parameter to the first (leftmost, high-order) word of its assigned
doubleword slot.  This is internally self-consistent but will not
interoperate correctly with libraries compiled with an ABI-compliant
compiler.

This patch corrects the problem by adjusting the parameter addressing
on both sides of the calling convention.

llvm-svn: 165714

llvm-svn: 165713

llvm-svn: 165712

Note: [D]M{T,F}CP2 is just a recommended encoding.  Vendors often provide a
custom CP2 that interprets instructions differently and may wish to add their
own instructions that use this opcode.  We should ensure that this is easy to
do.  I will probably add a 'has custom CP{0-3}' subtarget flag to make this
easy: We want to avoid the GCC situation where every MIPS vendor makes a custom
fork that breaks every other MIPS CPU and so can't be merged upstream.

llvm-svn: 165711

llvm-svn: 165710

llvm-svn: 165709

Patch from Preston Briggs <preston.briggs@gmail.com>.

This is an updated version of the dependence-analysis patch, including an MIV
test based on Banerjee's inequalities.

It's a fairly complete implementation of the paper

    Practical Dependence Testing
    Gina Goff, Ken Kennedy, and Chau-Wen Tseng
    PLDI 1991

It cannot yet propagate constraints between coupled RDIV subscripts (discussed
in Section 5.3.2 of the paper).

It's organized as a FunctionPass with a single entry point that supports testing
for dependence between two instructions in a function. If there's no dependence,
it returns null. If there's a dependence, it returns a pointer to a Dependence
which can be queried about details (what kind of dependence, is it loop
independent, direction and distance vector entries, etc). I haven't included
every imaginable feature, but there's a good selection that should be adequate
for supporting many loop transformations. Of course, it can be extended as
necessary.

Included in the patch file are many test cases, commented with C code showing
the loops and array references.

llvm-svn: 165708

llvm-svn: 165707

llvm-svn: 165705

with ~, we need to realpath it.  Fixes the case where

settings set target.expr-prefix ~/lldb.prefix.header

wouldn't read this prefix header file.  <rdar://problem/12475676> 

llvm-svn: 165704

malloc'ed heap to an llvm SmallVector.

llvm-svn: 165703

llvm-svn: 165701

llvm-svn: 165693

It broke stage2 clang and test-suite/MultiSource/Benchmarks/mediabench/g721/g721encode.

llvm-svn: 165692

llvm-svn: 165690

llvm-svn: 165689

llvm-svn: 165688

llvm-svn: 165687

llvm-svn: 165686

Support the following intrinsics:
  _mm_cvtph_ps, _mm256_cvtph_ps, _mm_cvtps_ph, _mm256_cvtps_ph

rdar://12407875

llvm-svn: 165685

is no longer necessary, as well as the little bit of infrastructure in
the AST writer that used it.

llvm-svn: 165684

llvm-svn: 165683

macro history.

When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.

There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.

Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.

llvm-svn: 165682

llvm-svn: 165681

value but later turns out to be a function.

Unfortunately, we can't fold tests into a single file because we only get one
error out of llvm-as.

llvm-svn: 165680

llvm-svn: 165679

Make sure we perform the variadic method check correctly for calls to a member operator().  PR14057.

llvm-svn: 165678

llvm-svn: 165677

This time, actually uncomment the code that's supposed to fix the problem.

This reverts r165671 / 8ceb837585ed973dc36fba8dfc57ef60fc8f2735.

llvm-svn: 165676

  auto x((unknown));
  int& y = x;

would crash because we were not flagging 'x' as an invalid declaration here.

llvm-svn: 165675