llvm-svn: 84207

Patch by Johnny Chen.

llvm-svn: 84206

is just "[Rn]" and no tailing comma with an offset, etc.

llvm-svn: 84205

llvm-svn: 84203

In the case where there are no good places to put constants and we fall back
upon inserting unconditional branches to make new blocks, allow all constant
pool references in range of those blocks to put constants there, even if that
means resetting the "high water marks" for those references.  This will still
terminate because you can't keep splitting blocks forever, and in the bad
cases where we have to split blocks, it is important to avoid splitting more
than necessary.

llvm-svn: 84202

as expressions, code for parsing a few arm specific directives (still needs
the MCStreamer calls for these).  Some clean up of the operand parsing code
and adding some comments.

llvm-svn: 84201

llvm-svn: 84200

Fix bug where array malloc with unexpected computation of the size argument resulted in MallocHelper 
identifying the malloc as a non-array malloc.  This broke GlobalOpt's optimization of stores of mallocs 
to global variables.

The fix is to classify malloc's into 3 categories:
1. non-array mallocs
2. array mallocs whose array size can be determined
3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized

getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their 
malloc optimization if this function returns NULL.

Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in
isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples.

llvm-svn: 84199

Implement <rdar://problem/7303432> [Clang/Index] In-memory-style AST generation API (initial API implementation).

Added clang_createTranslationUnitFromSourceFile().
Changed clang_createIndex() to lookup the location of clang (using dladdr).

llvm-svn: 84198

isn't implemented yet.
 - <rdar://problem/7297571> Clang should use pretokenized headers for C++ PCH
   files

llvm-svn: 84197

llvm-svn: 84196

llvm-svn: 84195

llvm-svn: 84194

llvm-svn: 84193

llvm-svn: 84192

llvm-svn: 84191

Fix pasto.

llvm-svn: 84190

llvm-svn: 84189

instantiation redeclaration semantics for function template
specializations and member functions of class template
specializations. Also, record the point of instantiation for
explicit-instantiated functions and static data members.

llvm-svn: 84188

sets of builtin operators. Currently, it is applied 
to '++' and '->*' operators. I need to apply it to others
as well. Also, heuristics need be applied to 
BuiltinCandidateTypeSet::AddPointerWithMoreQualifiedTypeVariants.
This is WIP.

llvm-svn: 84187

llvm-svn: 84186

specializations. Work in progress; there's more cleanup required to
actually use the new CheckSpecializationInstantiationRedecl checker
uniformly.

llvm-svn: 84185

PIC16Section class", it breaks globals.ll.

llvm-svn: 84184

llvm-svn: 84183

functions/static data members of class template specializations that
do not have definitions. This is the latter part of [temp.explicit]p4;
the former part still needs more testing.

llvm-svn: 84182

cases where an explicit instantiation requires a definition; the
remainder of these checks will come with the implementation of
paragraph 4 of [temp.explicit].

llvm-svn: 84181

derived from MCSection.

llvm-svn: 84180

llvm-svn: 84179

non-virtual part of the return result adjustments for covariant
thunks.  WIP.

llvm-svn: 84178

Pointed out by Gabor.

llvm-svn: 84177

llvm-svn: 84176

improve alias results if constant, and the source pointer can't be modified.

llvm-svn: 84175

llvm-svn: 84174

llvm-svn: 84173

When ARMConstantIslandPass cannot find any good locations (i.e., "water") to
place constants, it falls back to inserting unconditional branches to make a
place to put them.  My recent change exposed a problem in this area.  We may
sometimes append to the same block more than one unconditional branch.  The
symptoms of this are that the generated assembly has a branch to an undefined
label and running llc with -debug will cause a seg fault.

This happens more easily since my change to prevent CPEs from moving from
lower to higher addresses as the algorithm iterates, but it could have
happened before.  The end of the block may be in range for various constant
pool references, but the insertion point for new CPEs is not right at the end
of the block -- it is at the end of the CPEs that have already been placed
at the end of the block.  The insertion point could be out of range.  When
that happens, the fallback code will always append another unconditional
branch if the end of the block is in range.

The fix is to only append an unconditional branch if the block does not
already end with one.  I also removed a check to see if the constant pool load
instruction is at the end of the block, since that is redundant with
checking if the end of the block is in-range.

There is more to be done here, but I think this fixes the immediate problem.

llvm-svn: 84172

don't bother every time going around the main worklist.  This speeds up a 
release-asserts opt -std-compile-opts on 403.gcc by about 4% (1.5s).  It
seems to speed up the most expensive instances of instcombine by ~10%.

llvm-svn: 84171

instruction (which disqualifies stores, unreachable, etc) and at least the
first operand is a constant.  This filters out a lot of obvious cases that
can't be folded.  Also, switch the IRBuilder to a TargetFolder, which tries
harder.

llvm-svn: 84170

llvm-svn: 84169

most of the unsafe boilerplate out of TypeLoc.  Create a QualifiedLoc class
to represent the idea that we *might* start representing source locations
of qualifiers.  Dealing with qualifiers explicitly like this also lets us
efficiently ignore them in all the concrete cases.

This should make it obvious and easy to add new TypeLoc subclasses.

llvm-svn: 84168

llvm-svn: 84167