update all the callers.

llvm-svn: 82889

and makes the API more annoying.  Add a Regex::getNumMatches() method.

llvm-svn: 82877

calls, since direct calls don't always reflect the attributes of their
callees.

llvm-svn: 82867

to inttoptr/ptrtoint unnecessarily.

llvm-svn: 82864

there need to be corresponding changes to the constant folders,
done in this patch.

llvm-svn: 82862

where FCMP_OEQ is not legal and FCMP_OGE is, such as x86. 

llvm-svn: 82861

llvm-svn: 82838

llvm-svn: 82837

llvm-svn: 82836

allocatable. Even if it doesn't appear to have any defs, it may latter
on after register allocation.

llvm-svn: 82834

llvm-svn: 82825

llvm-svn: 82823

MathExtras.h in MachineMemOperand.h.

llvm-svn: 82822

llvm-svn: 82821

typically faster then doing a general pow.

llvm-svn: 82819

llvm-svn: 82818

which have no defs anywhere in the function. In particular, this fixes sinking
of instructions that reference RIP on x86-64, which is currently being modeled
as a register.

llvm-svn: 82815

llvm-svn: 82814

llvm-svn: 82812

and skipping the defs.

llvm-svn: 82811

llvm-svn: 82805

llvm-svn: 82803

appear to be misspellings, removed in favor of fabs*.

llvm-svn: 82796

 - Allocate MachineMemOperands and MachineMemOperand lists in MachineFunctions.
   This eliminates MachineInstr's std::list member and allows the data to be
   created by isel and live for the remainder of codegen, avoiding a lot of
   copying and unnecessary translation. This also shrinks MemSDNode.
 - Delete MemOperandSDNode. Introduce MachineSDNode which has dedicated
   fields for MachineMemOperands.
 - Change MemSDNode to have a MachineMemOperand member instead of its own
   fields with the same information. This introduces some redundancy, but
   it's more consistent with what MachineInstr will eventually want.
 - Ignore alignment when searching for redundant loads for CSE, but remember
   the greatest alignment.

Target-specific code which previously used MemOperandSDNodes with generic
SDNodes now use MemIntrinsicSDNodes, with opcodes in a designated range
so that the SelectionDAG framework knows that MachineMemOperand information
is available.

llvm-svn: 82794

naming scheme used in SelectionDAG, where there are multiple kinds
of "target" nodes, but "machine" nodes are nodes which represent
a MachineInstr.

llvm-svn: 82790

llvm-svn: 82788

Revert 82694 "Auto-upgrade malloc instructions to malloc calls." because it causes regressions in the nightly tests.

llvm-svn: 82784

before producing FSIN, FCOS, FSQRT.  If they aren't
so marked we have to assume they might set errno.

llvm-svn: 82781

allows appropriate backends to generate a sqrt instruction.

On x86, this isn't done at -O0 because we go through
FastISel instead.  This is a behavior change from before
this series of sqrt patches started.  I think this is OK
considering that compile speed is most important at -O0, but
could be convinced otherwise.

llvm-svn: 82778

llvm-svn: 82773

For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned.  For the older ARM APCS ABI, the stack
alignment is just always 4 bytes.  For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.

After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo.  This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4.  (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.

llvm-svn: 82767

Previously, it treated GV+28 GV+0 as different bases, and assumed they could
not alias.

llvm-svn: 82753

instructions. This fixes a PowerPC bug exposed by some unrelated
changes I'm working on.

llvm-svn: 82743

llvm-svn: 82742

interest for this, as it currently reserves a register rather than using
the scavenger for matierializing constants as needed.

Instead of scavenging registers on the fly while eliminating frame indices,
new virtual registers are created, and then a scavenged collectively in a
post-pass over the function. This isolates the bits that need to interact
with the scavenger, and sets the stage for more intelligent use, and reuse,
of scavenged registers.

For the time being, this is disabled by default. Once the bugs are worked out,
the current scavenging calls in replaceFrameIndices() will be removed and
the post-pass scavenging will be the default. Until then,
-enable-frame-index-scavenging enables the new code. Currently, only the
Thumb1 back end is set up to use it.

llvm-svn: 82734

delete a few blank lines.

llvm-svn: 82729

llvm-svn: 82727

; CHECK: movl {{%e[a-z][xi]}}, %eax

or whatever.

llvm-svn: 82717

llvm-svn: 82716

llvm-svn: 82715