funky bit-widths.

llvm-svn: 43225

operations so they work right for integers with funky
bit-widths.  For example, consider extending i48 to i64
on a 32 bit machine.  The i64 result is expanded to 2 x i32.
We know that the i48 operand will be promoted to i64, then
also expanded to 2 x i32.  If we had the expanded promoted
operand to hand, then expanding the result would be trivial.
Unfortunately at this stage we can only get hold of the
promoted operand.  So instead we kind of hand-expand, doing
explicit shifting and truncating to get the top and bottom
halves of the i64 operand into 2 x i32, which are then used
to expand the result.  This is harmless, because when the
promoted operand is finally expanded all this bit fiddling
turns into trivial operations which are eliminated either
by the expansion code itself or the DAG combiner.

llvm-svn: 43223

- Remove a bogus assertion.

llvm-svn: 43211

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