llvm-svn: 82773

llvm-svn: 82772

llvm-svn: 82771

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

Likewise for constant inbounds GEP.

llvm-svn: 82763

llvm-svn: 82759

llvm-svn: 82758

llvm-svn: 82756

llvm-svn: 82754

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

llvm-svn: 82753

this adjustment does not change the direction or the signs of the object
offsets, and the details of the offset calculations can be target-specific.
Also mention that for most targets this value is only used to generate debug
info.

llvm-svn: 82750

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

llvm-svn: 82731

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

CHECK strings, instead of canonicalizing the patterns directly.  This allows
Pattern to just contain a StringRef instead of std::string.

llvm-svn: 82713

the Pattern class.

llvm-svn: 82712

llvm-svn: 82711

llvm-svn: 82710

llvm-svn: 82709

llvm-svn: 82708

llvm-svn: 82707

functions with names that match the C library.

llvm-svn: 82701

llvm-svn: 82700

Reviewed by Devang Patel.

llvm-svn: 82694

LocalAreaOffset.  (We don't have any of those right now.)
PEI::calculateFrameObjectOffsets includes the absolute value of the
LocalAreaOffset in the cumulative offset value used to calculate the
stack frame size.  It then adds the raw value of the LocalAreaOffset
to the stack size.  For a StackGrowsDown target, that raw value is negative
and has the effect of cancelling out the absolute value that was added
earlier, but that obviously won't work for a StackGrowsUp target.  Change
to subtract the absolute value of the LocalAreaOffset.

llvm-svn: 82693

llvm-svn: 82692

rather structs passed by value.
This fixes PR5038.

llvm-svn: 82689

 - Apparently, I'm willing to do incredibly stupid things in the name of portability.

llvm-svn: 82685

unconditionally compute MMI even if the target doesn't support EH or Debug info, because the target may use it for other things, this fixes PR5036

llvm-svn: 82684

llvm-svn: 82683

LiveVariables add implicit kills to correctly track partial register kills. This works well enough and is fairly accurate. But coalescer can make it impossible to maintain these markers. e.g.

        BL <ga:sss1>, %R0<kill,undef>, %S0<kill>, %R0<imp-def>, %R1<imp-def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>, %LR<imp-def,dead>, %D0<imp-def>, ...
...
	%reg1031<def> = FLDS <cp#1>, 0, 14, %reg0, Mem:LD4[ConstantPool]
...
   	%S0<def> = FCPYS %reg1031<kill>, 14, %reg0, %D0<imp-use,kill>

When reg1031 and S0 are coalesced, the copy (FCPYS) will be eliminated the the implicit-kill of D0 is lost. In this case it's possible to move the marker to the FLDS. But in many cases, this is not possible. Suppose

	%reg1031<def> = FOO <cp#1>, %D0<imp-def>
...
   	%S0<def> = FCPYS %reg1031<kill>, 14, %reg0, %D0<imp-use,kill>

When FCPYS goes away, the definition of S0 is the "FOO" instruction. However, transferring the D0 implicit-kill to FOO doesn't work since it is the def of D0 itself. We need to fix this in another time by introducing a "kill" pseudo instruction to track liveness.

Disabling the assertion is not ideal, but machine verifier is doing that job now. It's important to know double-def is not a miscomputation since it means a register should be free but it's not tracked as free. It's a performance issue instead.

llvm-svn: 82677

Clean up LiveVariables and change how it deals with partial updates and kills. This also eliminate the horrible check which scan forward to the end of the basic block. It should be faster and more accurate.

llvm-svn: 82676

a trivial unittest would have caught.  This revision also adds the trivial
unittest.

llvm-svn: 82675

computation, and some cosmetics.

llvm-svn: 82660