Also cleaned up some comments in source files.

llvm-svn: 43674

llvm-svn: 43673

or getTypeSizeInBits as appropriate in ScalarReplAggregates.
The right change to make was not always obvious, so it would
be good to have an sroa guru review this.  While there I noticed
some bugs, and fixed them: (1) arrays of x86 long double have
holes due to alignment padding, but this wasn't being spotted
by HasStructPadding (renamed to HasPadding).  The same goes
for arrays of oddly sized ints.  Vectors also suffer from this,
in fact the problem for vectors is much worse because basic
vector assumptions seem to be broken by vectors of type with
alignment padding.   I didn't try to fix any of these vector
problems.  (2) The code for extracting smaller integers from
larger ones (in the "int union" case) was wrong on big-endian
machines for integers with size not a multiple of 8, like i1.
Probably this is impossible to hit via llvm-gcc, but I fixed
it anyway while there and added a testcase.  I also got rid of
some trailing whitespace and changed a function name which
had an obvious typo in it.

llvm-svn: 43672

If an interval is being undone clear its preference as well since the source interval may have been undone as well.

llvm-svn: 43670

regs on x86-64.

llvm-svn: 43669

metric is way off for these in general, and this works around
buggy code like that in PR1764.  we'll see if there is a big
performance impact of this.  If so, I'll revert it tomorrow.

llvm-svn: 43668

llvm-svn: 43667

Add a method prototype slot/getter to the ObjCMessageExpr AST.

llvm-svn: 43666

Implement rewrite rules for ObjC string constants.

llvm-svn: 43665

llvm-svn: 43663

can be eliminated by the allocator is the destination and source targets the
same register. The most common case is when the source and destination registers
are in different class. For example, on x86 mov32to32_ targets GR32_ which
contains a subset of the registers in GR32.

The allocator can do 2 things:
1. Set the preferred allocation for the destination of a copy to that of its source.
2. After allocation is done, change the allocation of a copy destination (if
   legal) so the copy can be eliminated.

This eliminates 443 extra moves from 403.gcc.

llvm-svn: 43662

ASTConsumer to process the AST before it is destroyed.
This allows elimination of HandleObjcMetaDataEmission.

llvm-svn: 43659

My previous patch did the same for @catch AST.

llvm-svn: 43654

llvm-svn: 43653

llvm-svn: 43652

llvm-svn: 43651

llvm-svn: 43649

key functions to implement.

llvm-svn: 43648

the target pointer to be passed by reference.  This can result in less
typing, as the object to be deserialized can be inferred from the
argument.

llvm-svn: 43647

llvm-svn: 43646

llvm-svn: 43645

llvm-svn: 43644

llvm-svn: 43643

llvm-svn: 43642

llvm-svn: 43641

llvm-svn: 43640

llvm-svn: 43639

Restore an assertion that arithmetic can be performed on this format.

llvm-svn: 43638

llvm-svn: 43637

llvm-svn: 43636

llvm-svn: 43633

llvm-svn: 43632

llvm-svn: 43631

llvm-svn: 43630

llvm-svn: 43629

llvm-svn: 43628

llvm-svn: 43627

memory rather than in a copy of the APFloat.  This avoids problems
when the destination is wider than our significand and is cleaner.

Also provide deterministic values in all cases where conversion
fails, namely zero for NaNs and the minimal or maximal value
respectively for underflow or overflow.

llvm-svn: 43626

updated it to the recently updated Serialization API.

Changed clients of SourceLocation serialization to call the
appropriate new methods.

Updated Decl serialization code to put new skeleton serialization code
in place that is much better than the older trait-specialization
approach.

llvm-svn: 43625

Deserializer.

There were issues with Visual C++ barfing when instantiating
SerializeTrait<T> when "T" was an abstract class AND
SerializeTrait<T>::ReadVal was *never* called:

template <typename T>
struct SerializeTrait {
 <SNIP>
  static inline T ReadVal(Deserializer& D) { T::ReadVal(D); }
 <SNIP>
};

Visual C++ would complain about "T" being an abstract class, even
though ReadVal was never instantiated (although one of the other
member functions were).

Removing this from the trait is not a big deal.  It was used hardly
ever, and users who want "read-by-value" deserialization can simply
call the appropriate methods directly instead of relying on
trait-based-dispatch.  The trait dispatch for
serialization/deserialization is simply sugar in many cases (like this
one).

llvm-svn: 43624