llvm-svn: 43204

with the new legalizer.

llvm-svn: 43199

llvm-svn: 43198

This fixes CodeGen/X86/mem*.ll.

llvm-svn: 43197

llvm-svn: 43196

the operand's type from the right place.

llvm-svn: 43195

Turn a store folding instruction into a load folding instruction. e.g.
     xorl  %edi, %eax
     movl  %eax, -32(%ebp)
     movl  -36(%ebp), %eax
     orl   %eax, -32(%ebp)
=>
     xorl  %edi, %eax
     orl   -36(%ebp), %eax
     mov   %eax, -32(%ebp)
This enables the unfolding optimization for a subsequent instruction which will
also eliminate the newly introduced store instruction.

llvm-svn: 43192

llvm-svn: 43191

llvm-svn: 43190

llvm-svn: 43189

llvm-svn: 43181

by Duncan

llvm-svn: 43177

llvm-svn: 43175

asserts in later checks rather than producing
the ordinary load it is supposed to.  Avoid all
such hassles by directly returning an ordinary
load in this case.

llvm-svn: 43174

To do this it is necessary to add a "always inline" argument to the
memcpy node. For completeness I have also added this node to memmove
and memset.  I have also added getMem* functions, because the extra
argument makes it cumbersome to use getNode and because I get confused
by it :-)

llvm-svn: 43172

llvm-svn: 43171

llvm-svn: 43170

llvm-svn: 43169

llvm-svn: 43167

llvm-svn: 43166

llvm-svn: 43165

llvm-svn: 43161

llvm-svn: 43160

llvm-svn: 43120

llvm-svn: 43119

traversing inverse register coalescing map.

llvm-svn: 43118

llvm-svn: 43072

types.  This is needed for SIGN_EXTEND_INREG at least.
It is not clear if this is correct for other operations.
On the other hand, for the various load/store actions
it seems to correct to return the type action, as is
currently done.
Also, it seems that SelectionDAG::getValueType can be
called for extended value types; introduce a map for
holding these, since we don't really want to extend
the vector to be 2^32 pointers long!
Generalize DAGTypeLegalizer::PromoteResult_TRUNCATE
and DAGTypeLegalizer::PromoteResult_INT_EXTEND to handle
the various funky possibilities that apints introduce,
for example that you can promote to a type that needs
to be expanded.

llvm-svn: 43071

llvm-svn: 43069

llvm-svn: 43065

their value numbers with the specified value number.

llvm-svn: 43062

llvm-svn: 43061

llvm-svn: 43060

Remove the assumption that this will happen from
various places.

llvm-svn: 43053

llvm-svn: 43043

llvm-svn: 43035

codegen support.  This should have no effect on codegen
for other types.  Debatable bits: (1) the use (abuse?)
of a set in SDNode::getValueTypeList; (2) the length of
getTypeToTransformTo, which maybe should be refactored
with a non-inline part for extended value types.

llvm-svn: 43030

being passed instead of an opcode; (2) ValueType being passed
for isVolatile (!) in getLoad.

llvm-svn: 43028

llvm-svn: 43026

work with type promotion on x86.

llvm-svn: 43025