1) ConstantFP is now expand by default
2) ConstantFP is not turned into TargetConstantFP during Legalize
   if it is legal.

This allows ConstantFP to be handled like Constant, allowing for 
targets that can encode FP immediates as MachineOperands.

As a bonus, fix up Itanium FP constants, which now correctly match,
and match more constants!  Hooray.

llvm-svn: 47121

llvm-svn: 47101

llvm-svn: 47098

to pass the mask APInt by value, not by reference. 

llvm-svn: 47096

CTTZ and CTPOP.  The expansion code differs from
that in LegalizeDAG in that it chooses to take the
CTLZ/CTTZ count from the Hi/Lo part depending on
whether the Hi/Lo value is zero, not on whether
CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the
width of the type is) for it.  I made this change
because the optimizers may well know that Hi/Lo
is zero and exploit it.  The promotion code for
CTTZ also differs from that in LegalizeDAG: it
uses an "or" to get the right result when the
original value is zero, rather than using a compare
and select.  This also means the value doesn't
need to be zero extended.

llvm-svn: 47075

node as soon as we create it in SDISel.  Previously we would lower it in
legalize.  The problem with this is that it only exposes the argument
loads implied by FORMAL_ARGUMENTs after legalize, so that only dag combine 2
can hack on them.  This causes us to miss some optimizations because 
datatype expansion also happens here.

Exposing the loads early allows us to do optimizations on them.  For example
we now compile arg-cast.ll to:

_foo:
	movl	$2147483647, %eax
	andl	8(%esp), %eax
	ret

where we previously produced:

_foo:
	subl	$12, %esp
	movsd	16(%esp), %xmm0
	movsd	%xmm0, (%esp)
	movl	$2147483647, %eax
	andl	4(%esp), %eax
	addl	$12, %esp
	ret

It might also make sense to do this for ISD::CALL nodes, which have implicit
stores on many targets.

llvm-svn: 47054

llvm-svn: 47052

type is not legal.

llvm-svn: 47048

Add an overload that supports the uint64_t interface for use by clients
that haven't been updated yet.

llvm-svn: 47039

handle arbitrary precision integers and any number
of parts.  For example, on a 32 bit machine an i50
corresponds to two i32 parts.  getCopyToParts will
extend the i50 to an i64 then write half of the i64
to each part; getCopyFromParts will combine the two
i32 parts into an i64 then truncate the result to
i50.

llvm-svn: 47024

in preparation for apint support.  These changes are
intended to have no functional effect.

llvm-svn: 46967

llvm-svn: 46964

llvm-svn: 46963

llvm-svn: 46962

Added member template "Add" to FoldingSetNodeID that allows "adding" arbitrary
objects to a profile via dispatch to FoldingSetTrait<T>::Profile().

Removed FoldingSetNodeID::AddAPFloat and FoldingSetNodeID::APInt, as their
functionality is now replaced using the above mentioned member template.

llvm-svn: 46957

llvm-svn: 46954

llvm-svn: 46930

llvm-svn: 46926

no-op).

llvm-svn: 46922

begin adding some methods to use it this way.

llvm-svn: 46899

llvm-svn: 46876

to return pointers instead of references, since this is always what
is needed.

llvm-svn: 46857

initializer problem, a minor tweak to the way the
DAGISelEmitter finds load/store nodes, and a renaming of the
new PseudoSourceValue objects.

llvm-svn: 46827

llvm-svn: 46776

llvm-svn: 46725

ReadyToProcess node - add an assertion to check
this.  Add an assertion to NodeDeleted that checks
that processed/ready nodes are indeed not deleted.
It is because they are never deleted that none of
the maps can have a deleted node as the source of
a mapping.  It does however seem to be possible in
theory to have a deleted value as the target of a
mapping, however this has not yet been spotted in
the wild.  Still mulling on what to do about this.
[The theoretical situation is this: a node A is
expanded/promoted/whatever to a newly created node
B.  Thus A->B is added to a map.  When the subtree
rooted at B is legalized it is conceivable that B
is deleted due to RAUW on a node somewhere above
it].

llvm-svn: 46705

llvm-svn: 46682

multiple times due to a RAUW.

llvm-svn: 46680

keep the LegalizeTypes node flags up to date when doing a RAUW.
This fixes a nasty bug that Duncan ran into and makes the 
previous (nonbuggy case) more efficent.

llvm-svn: 46679

llvm-svn: 46678

DAGUpdateListener object pointer instead of just returning a vector 
of deleted nodes.  This makes the interfaces more efficient (no more
allocating a vector [at least a malloc], filling it in, then walking
it) and more clean.  This also allows the client to be notified of
nodes that are *changed* but not deleted.

llvm-svn: 46677

SelectionDAG::ReplaceAllUsesWith to handle replacement of
an SDOperand with *any* sdoperand, not just one for a node with
a single result.  Note that this has a horrible FIXME'd hack in it
to work around PR1975.  This should be removed when PR1975 is fixed.

llvm-svn: 46674

llvm-svn: 46672

SDIsel processes llvm.dbg.declare by recording the variable debug information descriptor and its corresponding stack frame index in MachineModuleInfo. This only works if the local variable is "homed" in the stack frame. It does not work for byval parameter, etc.
Added ISD::DECLARE node type to represent llvm.dbg.declare intrinsic. Now the intrinsic calls are lowered into a SDNode and lives on through out the codegen passes.
For now, since all the debugging information recording is done at isel time, when a ISD::DECLARE node is selected, it has the side effect of also recording the variable. This is a short term solution that should be fixed in time.

llvm-svn: 46659

Remove the nasty LABEL hack with a much less evil one. Now llvm.dbg.func.start implies a stoppoint is set. SelectionDAGISel records a new source line but does not create a ISD::LABEL node for this special stoppoint. Asm printer will magically print this label. This ensures nothing is emitted before.

llvm-svn: 46635

llvm-svn: 46628

llvm-svn: 46623

llvm-svn: 46610

Add an extra operand to LABEL nodes which distinguishes between debug, EH, or misc labels. This fixes the EH breakage. However I am not convinced this is *the* solution.

llvm-svn: 46609

llvm-svn: 46605