llvm-svn: 119754

llvm-svn: 119753

types was not being generated for objc pointers.
// rdar://8681766.

llvm-svn: 119751

externally-defined variables to match up with
the code in ClangASTSource that produces them.

llvm-svn: 119750

Fix bug in DAGCombiner for ARM that was trying to do a ShiftCombine on illegal types (vector should be split first).
Added test case.

llvm-svn: 119749

Neon shifts allow a mix of positive and negative shift amounts to shift
left or right, respectively, so the shift amount vector should always be
signed.  PR8482 (Radar 8603521).

llvm-svn: 119748

should delete what when the object gets copied around. It's also making valgrind
upset.

llvm-svn: 119747

llvm-svn: 119746

llvm-svn: 119745

llvm-svn: 119744

llvm-svn: 119743

This makes it symmetric with the 'u' modifier that forces an unsigned type.
This is needed for unsigned vector shifts, where the shift amount still needs
to be signed.  PR8482 (Radar 8603521).

llvm-svn: 119742

llvm-svn: 119741

llvm-svn: 119740

not anyext(select).  Spotted by Frits van Bommel.

llvm-svn: 119739

This function was being called from two different places for completely
unrelated reasons.  During type legalization, it was called to expand 64-bit
shift operations.  During operation legalization, it was called to handle
Neon vector shifts.  The vector shift code was not written to check for
illegal types, since it was assumed to be only called after type legalization.
Fixed this by splitting off the 64-bit shift expansion into a separate
function.  I don't have a particular testcase for this; I just noticed it
by inspection.

llvm-svn: 119738

llvm-svn: 119737

and just check the number of errors from the DiagnosticClient.

llvm-svn: 119736

llvm-svn: 119735

llvm-svn: 119734

llvm-svn: 119733

llvm-svn: 119732

of the total number of warnings/errors reported.

llvm-svn: 119731

-Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class.
-DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units.
-The rest of the state in Diagnostic object is considered related and tied to one translation unit.
-Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a
   SourceLocation instead of a FullSourceLoc.
-Reflect the changes to various interfaces.

llvm-svn: 119730

llvm-svn: 119729

if the extension types were not the same.  The result was that if you
fed a select with sext and zext loads, as in the testcase, then it
would get turned into a zext (or sext) of the select, which is wrong
in the cases when it should have been an sext (resp. zext).  Reported
and diagnosed by Sebastien Deldon.

llvm-svn: 119728

preserves LCSSA form out of ScalarEvolution and into the LoopInfo
class.  Use it to check that SimplifyInstruction simplifications
are not breaking LCSSA form.  Fixes PR8622.

llvm-svn: 119727

llvm-svn: 119726

Remove movePastCSLoadStoreOps and associated code for simple pointer
increments. Update routines that depended upon other opcodes for save/restore.

Adjust all testcases accordingly.

llvm-svn: 119725

out because there are still bugs left.

llvm-svn: 119722

LLVMContext, causing memory errors.  Patch by Peter Collingbourne.

llvm-svn: 119721

by being able to get the data count and data. Each thread stop reason
has one or more data words that can help describe the stop. To do this
I added:

    size_t
	SBThread::GetStopReasonDataCount();

	uint64_t
	SBThread::GetStopReasonDataAtIndex(uint32_t idx);

llvm-svn: 119720

llvm-svn: 119719

Use thread-safe statics to avoid a static constructor here.  This isn't thread-safe on MSVC, but we don't
support threaded LLVM there anyways.

llvm-svn: 119718

llvm-svn: 119717

llvm-svn: 119716

Completely rework the datastructure GVN uses to represent the value number to leader mapping.  Previously,
this was a tree of hashtables, and a query recursed into the table for the immediate dominator ad infinitum
if the initial lookup failed.  This led to really bad performance on tall, narrow CFGs.

We can instead replace it with what is conceptually a multimap of value numbers to leaders (actually
represented by a hashtable with a list of Value*'s as the value type), and then
determine which leader from that set to use very cheaply thanks to the DFS numberings maintained by
DominatorTree.  Because there are typically few duplicates of a given value, this scan tends to be
quite fast.  Additionally, we use a custom linked list and BumpPtr allocation to avoid any unnecessary
allocation in representing the value-side of the multimap.

This change brings with it a 15% (!) improvement in the total running time of GVN on 403.gcc, which I
think is pretty good considering that includes all the "real work" being done by MemDep as well.

The one downside to this approach is that we can no longer use GVN to perform simple conditional progation,
but that seems like an acceptable loss since we now have LVI and CorrelatedValuePropagation to pick up
the slack.  If you see conditional propagation that's not happening, please file bugs against LVI or CVP.

llvm-svn: 119714

instruction. Any that may be expanded otherwise by MC lowering should
override this value. rdar://8683274

llvm-svn: 119713

llvm-svn: 119712

llvm-svn: 119711