llvm-svn: 147013

llvm-svn: 147012

llvm-svn: 147011

the build bot in some cases.  The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type.  It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext.  We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.

Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is 
pretty great that way.

llvm-svn: 147010

llvm-svn: 147009

nodes needed for multiplication. Add code for selecting 64-bit MULHS and MULHU
nodes.

llvm-svn: 147008

llvm-svn: 147007

reasonable-looking but ill-formed for-range statement of the form:

  for (expression : expression)

llvm-svn: 147006

llvm-svn: 147005

llvm-svn: 147004

llvm-svn: 147003

type is a pointer to const. (radar://10595327)

The regions corresponding to the pointer and reference arguments to
a function get invalidated by the calls since a function call can
possibly modify the pointed to data. With this change, we are not going
to invalidate the data if the argument is a pointer to const. This
change makes the analyzer more optimistic in reporting errors.
(Support for C, C++ and Obj C)

llvm-svn: 147002

only when the target ABI is N64.

llvm-svn: 147001

llvm-svn: 147000

MIPS64 can generate constant +0.0 with a single DMTC1 instruction. 

llvm-svn: 146999

in class method instead of crash. // rdar://10593227

llvm-svn: 146998

Use the spill slot alignment as well as the local variable alignment to
determine when the stack needs to be realigned. This works now that the
ARM target can always realign the stack by using a base pointer.

Still respect the ARMBaseRegisterInfo::canRealignStack() function
vetoing a realigned stack.  Don't use aligned spill code in that case.

llvm-svn: 146997

llvm-svn: 146996

llvm-svn: 146995

notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.

llvm-svn: 146994

llvm-svn: 146993

only when the target ABI is N64. 

llvm-svn: 146992

llvm-svn: 146990

llvm-svn: 146989

llvm-svn: 146988

llvm-svn: 146987

llvm-svn: 146986

llvm-svn: 146985

Patch by Andrew Wilkins!

llvm-svn: 146984

llvm-svn: 146983

Patch by Dimitry Andric!

llvm-svn: 146982

llvm-svn: 146981

visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.

As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.

Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.

llvm-svn: 146980

llvm-svn: 146978

(Both used for Linux gnueabi)
No behavioral change yet (no tests need so far)

llvm-svn: 146977

the definition of that class. Fixes PR11613 / <rdar://problem/10604077>.

llvm-svn: 146976

The failure that I see in the current version is:

LLVM ERROR: Cannot select: 0x18b8f70: v4i64 = X86ISD::VZEXT_MOVL 0x18beee0 [ID=14]
  0x18beee0: v4i64 = insert_subvector 0x18b8c70, 0x18b9170, 0x18b9570 [ID=13]
    0x18b8c70: v4i64 = insert_subvector 0x18b9870, 0x18bf4e0, 0x18b9970 [ID=12]
      0x18b9870: v4i64 = undef [ID=4]
      0x18bf4e0: v2i64 = bitcast 0x18bf3e0 [ID=10]
        0x18bf3e0: v4i32 = BUILD_VECTOR 0x18b9770, 0x18b9770, 0x18b9770, 0x18b9770 [ID=8]
          0x18b9770: i32 = TargetConstant<0> [ID=6]
          0x18b9770: i32 = TargetConstant<0> [ID=6]
          0x18b9770: i32 = TargetConstant<0> [ID=6]
          0x18b9770: i32 = TargetConstant<0> [ID=6]
      0x18b9970: i32 = Constant<0> [ID=3]
    0x18b9170: v2i64 = undef [ORD=1] [ID=1]
    0x18b9570: i32 = Constant<2> [ID=5]

llvm-svn: 146975

use the zero-undefined variants of CTTZ and CTLZ. These are just simple
patterns for now, there is more to be done to make real world code using
these constructs be optimized and codegen'ed properly on X86.

The existing tests are spiffed up to check that we no longer generate
unnecessary cmov instructions, and that we generate the very important
'xor' to transform bsr which counts the index of the most significant
one bit to the number of leading (most significant) zero bits. Also they
now check that when the variant with defined zero result is used, the
cmov is still produced.

llvm-svn: 146974

Pulling the template implementation into the header to guarantee
that it's visible to all possible instantiations.

llvm-svn: 146973

In case we can not analyze an access function, we do not discard the SCoP, but
assume conservatively that all memory accesses that can be derived from our base
pointer may be accessed.

Patch provided by: Marcello Maggioni <hayarms@gmail.com>

llvm-svn: 146972