llvm-svn: 119050

llvm-svn: 119049

llvm-svn: 119048

the Stmt* visitation in CursorVisitor to be
data-recursive.

Since AnnotationTokensWorker explicitly calls
CursorVisitor::VisitChildren(), it essentially
transforms the data-recursive algorithm in
CursorVisitor back into a non-data recursive one.
This is particularly bad because the data-recursive
algorithm uses more stack space per stack frame,
which can cause us to blow the stack in some cases.

"Fix" this by making the stack that AnnotationTokensWorker
runs in really huge.  The real fix is to modify
AnnotationTokensWorker not to do the explicit
recursive call.

llvm-svn: 119047

'LangOptionsBase' that default initializes all flags to 0.  Now the ctor of LangOptions
only initializes the flags that might be non-zero (significantly simplifying things).

This also appeases Valgrind on Mac OS X, which no longer reports that one of the flags
may be uninitialized.

llvm-svn: 119045

Elidable CXXConstructExpr should inhibit calling destructor for temporary 
that is copied, not the one created. This is because eliding copy constructor 
means that the object that was to be copied will be constructed directly in 
memory the copy would be constructed in.

llvm-svn: 119044

offload the work to hasConstantValue rather than do something more
complicated (such handling mutually recursive phis) because (1) it is
not clear it is worth it; and (2) if it is worth it, maybe such logic
would be better placed in hasConstantValue.  Adjust some GVN tests
which are now cleaned up much further (eg: all phi nodes are removed).

llvm-svn: 119043

operands are the phi node itself or undef, then return undef.
This logic already existed at a higher level so in practice it
shouldn't make the slightest difference.  Note that this code
could be replaced by a call to PN->hasConstantValue().  However
since we bail out the moment we see a non-constant operand, it
is more efficient to have a specialized version of that logic.

llvm-svn: 119041

llvm-svn: 119040

llvm-svn: 119038

Return the result of a complex assignment with the original values,
not by performing a load from the l-value;  this is the correct
semantics in C, although not in C++.

llvm-svn: 119037

implicit conversions;  the last batch was specific to promotions.
I think this is the full set we need.  I do think dividing the cast
kinds into floating and integral is probably a good idea.

Annotate a *lot* more C casts with useful cast kinds.

llvm-svn: 119036

llvm-svn: 119035

llvm-svn: 119034

llvm-svn: 119033

llvm-svn: 119032

llvm-svn: 119031

covered by the normal recursive visitation.

llvm-svn: 119030

llvm-svn: 119029

llvm-svn: 119028

somehow got several block tests fail with a linux built
compiler.

llvm-svn: 119027

signature symbol causes a local symbol to be created unless there is
some other use of the symbol.

llvm-svn: 119026

llvm-svn: 119025

test/CodeGenCXX/dyncast.cpp: Remove XFAIL:win32 with tweaking llvm/utils/FileCheck in r119023, due to DOSish crlf issue.

llvm-svn: 119024

It can pass two tests below on Win32.
  - Clang :: CodeGenCXX/dyncast.cpp
  - LLVM :: CodeGen/ARM/globals.ll

llvm-svn: 119023

the symbols.

llvm-svn: 119022

llvm-svn: 119021

types to their full definitions more than we needed to. This caused an assertion
in the DWARF parser to fire -- which is an indication that we are parsing too much.

llvm-svn: 119020

breakpoints on inlined functions by name. This involved fixing the DWARF parser
to correctly back up and parse the concrete function when we find inlined
functions by name, then grabbing any appropriate inlined blocks and returning
symbol contexts with the block filled in. After this was fixed, the breakpoint
by name resolver needed to correctly deal with symbol contexts that had the
inlined block filled in in the symbol contexts.

llvm-svn: 119017

llvm-svn: 119014

on the built compiler.

llvm-svn: 119013

a debug map with DWARF in the .o files due to the attemted shortcut that was
being taken where the global variables were being searched for by looking in
the symbol table. The problem with the symbols in the symbol table is we don't
break apart the symbol names for symbols when they are mangled into basename
and the fully mangled name since this would take a lot of CPU time to chop up
the mangled names and try and find the basenames. The DWARF info typically has
this broken up for us where the basename of the variable is in a the DW_AT_name
attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute.
Now we correctly find globals by searching all OSO's for the information so we
can take advantage of this split information. 

llvm-svn: 119012

copy helper function and dtor of copied cxx objects
in dispose helper functions. __block variables
TBD next.

llvm-svn: 119011

as it goes").  Before -std-compile-opts only got it down to
  %a = tail call i32 @foo(i32 0) readnone
  %x = tail call i32 @foo(i32 %a) readnone
  %y = tail call i32 @foo(i32 %a) readnone
  %z = icmp eq i32 %x, %y
  ret i1 %z
while now -basicaa -gvn alone reduce it to
  %a = call i32 @foo(i32 0) readnone
  %x = call i32 @foo(i32 %a) readnone
  ret i1 true

llvm-svn: 119009

binary operator, provide the types.

llvm-svn: 119008

llvm-svn: 119007

llvm-svn: 119006

(while computing user conversion sequences), make sure that a result
of class type is a complete class type. Had we gone through
ActOnCallExpr, this would have happened when we built the CallExpr.

Fixes PR8425.

llvm-svn: 119005

llvm-svn: 119003

SimplifyAssociativeOrCommutative) "(A op C1) op C2" -> "A op (C1 op C2)",
which previously was only done if C1 and C2 were constants, to occur whenever
"C1 op C2" simplifies (a la InstructionSimplify).  Since the simplifying operand
combination can no longer be assumed to be the right-hand terms, consider all of
the possible permutations.  When compiling "gcc as one big file", transform 2
(i.e. using right-hand operands) fires about 4000 times but it has to be said
that most of the time the simplifying operands are both constants.  Transforms
3, 4 and 5 each fired once.  Transform 6, which is an existing transform that
I didn't change, never fired.  With this change, the testcase is now optimized
perfectly with one run of instcombine (previously it required instcombine +
reassociate + instcombine, and it may just have been luck that this worked).

llvm-svn: 119002