llvm-svn: 100093

llvm-svn: 100092

1. Makes it possible to lower with floating point loads and stores.
2. Avoid unaligned loads / stores unless it's fast.
3. Fix some memcpy lowering logic bug related to when to optimize a
   load from constant string into a constant.
4. Adjust x86 memcpy lowering threshold to make it more sane.
5. Fix x86 target hook so it uses vector and floating point memory
   ops more effectively.
rdar://7774704

llvm-svn: 100090

llvm-svn: 100089

being a TrackingVH<MDNode> to a NewDebugLoc, shrinking 
sizeof(Instruction) a lot, and providing clients the ability
to deal with locations in terms of NewDebugLoc instead of
having to deal with Metadata.  This is still fully compatible
with all clients that *do* use MDNodes for everything of
course.

No functionality change.

llvm-svn: 100088

llvm-svn: 100087

to used deferred resolution instead of creating a temporary
node + rauw.  There is no reason to create the temporary
mdnode, then do rauw, then destroy it.

llvm-svn: 100086

MD used here isn't valid for !dbg.

llvm-svn: 100085

entry in the Scope+InlinedAt drops to a non-canonical form,
we need to reset the idx member of both VH's to 0.

llvm-svn: 100084

llvm-svn: 100083

llvm-svn: 100082

llvm-svn: 100081

llvm-svn: 100080

llvm-svn: 100079

aes instead of sse4.2.  Add a brief todo for a subtarget flag and rework
the aeskeygenassist instruction to more closely match the docs.

llvm-svn: 100078

llvm-svn: 100077

llvm-svn: 100076

llvm-svn: 100074

and will replace the 'DbgInfo' member in Instruction.

The benefit of NewDebugLoc is that it is compact (8 bytes vs 12/24 
bytes for the DbgInfo member in Instruction on a 32/64 bit system),
it means that we will end up not having to allocate MDNodes to 
represent the "DILocations" in common cases of -O0 -g, and it is
much more efficient to get things out of than the MDNode.

llvm-svn: 100072

array values with a non-zero offset would get prematurely pruned from the store.

llvm-svn: 100067

llvm-svn: 100066

llvm-svn: 100065

llvm-svn: 100064

llvm-svn: 100062

nested-name-specifier (e.g., "class T::foo") fails to find a tag
member in the scope nominated by the
nested-name-specifier. Previously, we gave a bland

  error: 'Nested' does not name a tag member in the specified scope

which didn't actually say where we were looking, which was rather
horrible when the nested-name-specifier was instantiated. Now, we give
something a bit better:

  error: no class named 'Nested' in 'NoDepBase<T>'

llvm-svn: 100060

llvm-svn: 100058

* Set the "DestA" and "DestB" according to how they're understood by the
  method. I.e., if one or both of them should point to the "fall through" block,
  then point to the fall through block.

* Improve the loop that removes superfluous edges to be more understandable.

llvm-svn: 100056

llvm-svn: 100055

(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.

Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.

There is still much testing and cleanup to do in this area.

llvm-svn: 100054

llvm-svn: 100050

Debug info can now properly represent functions inside classes inside other functions.  Partial fix for Radar 7424645.

llvm-svn: 100048

PHIs.  The previous algorithm was unable to reliably detect when existing
PHIs in a cycle can be reused.  I'm still working on reducing a testcase.
Radar 7711900.

llvm-svn: 100047

llvm-svn: 100045

generate wrong code pretty much anywhere AFAICT.
A case that hits the bug reproducibly is impossible,
but the situation was like this:
Addr = ...
Store -> Addr
Addr2 = GEP , 0, 0
Store -> Addr2
Handling the first store, the code changed replaced Addr
with a sunkaddr and deleted Addr, but not its table
entry.  Code in OptimizedBlock replaced Addr2 with a
bitcast; if that happened to reuse the memory of Addr,
the old table entry was erroneously found when handling
the second store.

llvm-svn: 100044

llvm-svn: 100043

llvm-svn: 100042

ares are not separated by ':' (radar 7030268).

llvm-svn: 100040

this was parsed as a typename-specifier, elaborated-type-specifier
(including the kind), or just a dependent qualified type name.

llvm-svn: 100039

llvm-svn: 100038

llvm-svn: 100037