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

llvm-svn: 119001

llvm-svn: 119000

llvm-svn: 118999

llvm-svn: 118998

- Get the opcode once.
- Add a ParserMatchClass to reglist.

llvm-svn: 118997

llvm-svn: 118996

future to separate out the ia, ib, da, db variants of the load/store multiple
instructions.

llvm-svn: 118995

between complex types.

llvm-svn: 118994

operands appropriately.  There are a lot of missing complex-related
cast kinds.

llvm-svn: 118993

 - What was I thinking?????

llvm-svn: 118992

CXXConstructExpr.

llvm-svn: 118991

llvm-svn: 118990

llvm-svn: 118989

promoted arithmetic types for which builtin operator candidates are
emitted.  A few of these need further analysis.

Removes all the uses of UsualArithmeticConversionsType except the
core function in SemaExpr.cpp.

llvm-svn: 118988

llvm-svn: 118987

its children and then reverse them.

llvm-svn: 118986

llvm-svn: 118985

BlockEdges, BlockEntrances, and BlockExits for the target block value.

llvm-svn: 118984

worklist that could have impacted the evaluation of a block.

Fixes <rdar://problem/8663596>.

llvm-svn: 118983

This API required changing the BFS worklist to use a deque instead of a queue, but that is better
for performance reasons anyway.

llvm-svn: 118982

llvm-svn: 118981

llvm-svn: 118980

expression. This currently takes waaaayyyyy too much time to evaluate. We will
need to look at the expression parser and find ways to optimize the info we
provide and get this to evaluate quicker. I believe the performance issue is
currently related to us always providing a complete C++ class type when asked
about a C++ class which can cause a lot of information to be pulled since all
classes will be fully created (methods, base classes, members, all their 
types). We will need to give the classes back the parser and mark them as 
having external sources and get parser (Sema) to query us when it needs more
info. This should bring things up to an acceptable level.

llvm-svn: 118979

llvm-svn: 118978