Commit Graph

73 Commits

Author SHA1 Message Date
Jakob Stoklund Olesen 3c52f0281f Add an MF argument to TRI::getPointerRegClass() and TII::getRegClass().
The getPointerRegClass() hook can return register classes that depend on
the calling convention of the current function (ptr_rc_tailcall).

So far, we have been able to infer the calling convention from the
subtarget alone, but as we add support for multiple calling conventions
per target, that no longer works.

Patch by Yiannis Tsiouris!

llvm-svn: 156328
2012-05-07 22:10:26 +00:00
Preston Gurd 9a0914753a This patch fixes a problem which arose when using the Post-RA scheduler
on X86 Atom. Some of our tests failed because the tail merging part of
the BranchFolding pass was creating new basic blocks which did not
contain live-in information. When the anti-dependency code in the Post-RA
scheduler ran, it would sometimes rename the register containing
the function return value because the fact that the return value was
live-in to the subsequent block had been lost. To fix this, it is necessary
to run the RegisterScavenging code in the BranchFolding pass.

This patch makes sure that the register scavenging code is invoked
in the X86 subtarget only when post-RA scheduling is being done.
Post RA scheduling in the X86 subtarget is only done for Atom.

This patch adds a new function to the TargetRegisterClass to control
whether or not live-ins should be preserved during branch folding.
This is necessary in order for the anti-dependency optimizations done
during the PostRASchedulerList pass to work properly when doing
Post-RA scheduling for the X86 in general and for the Intel Atom in particular.

The patch adds and invokes the new function trackLivenessAfterRegAlloc()
instead of using the existing requiresRegisterScavenging().
It changes BranchFolding.cpp to call trackLivenessAfterRegAlloc() instead of
requiresRegisterScavenging(). It changes the all the targets that
implemented requiresRegisterScavenging() to also implement
trackLivenessAfterRegAlloc().  

It adds an assertion in the Post RA scheduler to make sure that post RA
liveness information is available when it is needed.

It changes the X86 break-anti-dependencies test to use –mcpu=atom, in order
to avoid running into the added assertion.

Finally, this patch restores the use of anti-dependency checking
(which was turned off temporarily for the 3.1 release) for
Intel Atom in the Post RA scheduler.

Patch by Andy Zhang!

Thanks to Jakob and Anton for their reviews.

llvm-svn: 155395
2012-04-23 21:39:35 +00:00
Craig Topper b35eacb0f0 Use uint16_t instead of unsigned to store registers in reg classes. Reduces static data size.
llvm-svn: 151998
2012-03-04 10:16:38 +00:00
Craig Topper 420525ce3b Use uint16_t to store registers in callee saved register tables to reduce size of static data.
llvm-svn: 151996
2012-03-04 03:33:22 +00:00
Jia Liu b22310fda6 Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore.
llvm-svn: 150878
2012-02-18 12:03:15 +00:00
Jakob Stoklund Olesen fdbb12b235 Implement ARMBaseRegisterInfo::getCallPreservedMask().
Move ARM callee-saved lists into ARMCallingConv.td.

llvm-svn: 148357
2012-01-17 23:09:00 +00:00
Evan Cheng 801d98b3f0 Fix more places which should be checking for iOS, not darwin.
llvm-svn: 147513
2012-01-04 01:55:04 +00:00
Jakob Stoklund Olesen c7b437ae34 Emit a getMatchingSuperRegClass() implementation for every target.
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().

Delete the old manual, error-prone implementations in the targets.

llvm-svn: 146873
2011-12-19 16:53:34 +00:00
Evan Cheng e891654a58 Change ARM / Thumb2 addc / adde and subc / sube modeling to use physical
register dependency (rather than glue them together). This is general
goodness as it gives scheduler more freedom. However it is motivated by
a nasty bug in isel.

When a i64 sub is expanded to subc + sube.
  libcall #1
     \
      \        subc 
       \       /  \
        \     /    \
         \   /    libcall #2
          sube

If the libcalls are not serialized (i.e. both have chains which are dag
entry), legalizer can serialize them in arbitrary orders. If it's
unlucky, it can force libcall #2 before libcall #1 in the above case.

  subc
   |
  libcall #2
   |
  libcall #1
   |
  sube

However since subc and sube are "glued" together, this ends up being a
cycle when the scheduler combine subc and sube as a single scheduling
unit.

The right solution is to fix LegalizeType too chains the libcalls together.
However, LegalizeType is not processing nodes in order so that's harder than
it should be. For now, the move to physical register dependency will do.

rdar://10019576

llvm-svn: 138791
2011-08-30 01:34:54 +00:00
Jim Grosbach b7fa2c0a53 Thumb parsing diagnostics for low-reg requirements on ADD and MOV.
llvm-svn: 137779
2011-08-16 22:20:01 +00:00
Evan Cheng d60fa58ba1 Sink getDwarfRegNum, getLLVMRegNum, getSEHRegNum from TargetRegisterInfo down
to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.

llvm-svn: 135424
2011-07-18 20:57:22 +00:00
Evan Cheng d9997acd14 Merge XXXGenRegisterDesc.inc XXXGenRegisterNames.inc XXXGenRegisterInfo.h.inc
into XXXGenRegisterInfo.inc.

llvm-svn: 133922
2011-06-27 18:32:37 +00:00
Jakob Stoklund Olesen 801f7ab321 Rename TRI::getAllocationOrder() to getRawAllocationOrder().
Also switch the return type to ArrayRef<unsigned> which works out nicely
for ARM's implementation of this function because of the clever ArrayRef
constructors.

The name change indicates that the returned allocation order may contain
reserved registers as has been the case for a while.

llvm-svn: 133216
2011-06-16 23:31:16 +00:00
Rafael Espindola 08600bcf65 Use the dwarf->llvm mapping to print register names in the cfi
directives.

Fixes PR9826.

llvm-svn: 132317
2011-05-30 20:20:15 +00:00
Jakob Stoklund Olesen 803a200077 Add a TRI::getLargestLegalSuperClass hook to provide an upper limit on register class inflation.
The hook will be used by the register allocator when recomputing register
classes after removing constraints.

Thumb1 code doesn't allow anything larger than tGPR, and x86 needs to ensure
that the spill size doesn't change.

llvm-svn: 130228
2011-04-26 18:52:33 +00:00
Bob Wilson df612ba006 Avoid write-after-write issue hazards for Cortex-A9.
Add a avoidWriteAfterWrite() target hook to identify register classes that
suffer from write-after-write hazards. For those register classes, try to avoid
writing the same register in two consecutive instructions.

This is currently disabled by default.  We should not spill to avoid hazards!
The command line flag -avoid-waw-hazard can be used to enable waw avoidance.

llvm-svn: 129772
2011-04-19 18:11:45 +00:00
Cameron Zwarich df61694417 Move getRegPressureLimit() from TargetLoweringInfo to TargetRegisterInfo.
llvm-svn: 127175
2011-03-07 21:56:36 +00:00
Anton Korobeynikov a8d177b2d4 Implement frame unwinding information emission for Thumb1. Not finished yet because there is no way given the constpool index to examine the actual entry: the reason is clones inserted by constant island pass, which are not tracked at all! The only connection is done during asmprinting time via magic label names which is really gross and needs to be eventually fixed.
llvm-svn: 127104
2011-03-05 18:43:50 +00:00
Bill Wendling 3fff1fd49b During local stack slot allocation, the materializeFrameBaseRegister function
may be called. If the entry block is empty, the insertion point iterator will be
the "end()" value. Calling ->getParent() on it (among others) causes problems.

Modify materializeFrameBaseRegister to take the machine basic block and insert
the frame base register at the beginning of that block. (It's very similar to
what the code does all ready. The only difference is that it will always insert
at the beginning of the entry block instead of after a previous materialization
of the frame base register. I doubt that that matters here.)

<rdar://problem/8782198>

llvm-svn: 122104
2010-12-17 23:09:14 +00:00
Anton Korobeynikov 7283b8d18c Move more PEI-related hooks to TFI
llvm-svn: 120229
2010-11-27 23:05:25 +00:00
Anton Korobeynikov 4687778398 Move some more hooks to TargetFrameInfo
llvm-svn: 119904
2010-11-20 15:59:32 +00:00
Anton Korobeynikov 0eecf5d201 Move hasFP() and few related hooks to TargetFrameInfo.
llvm-svn: 119740
2010-11-18 21:19:35 +00:00
Eric Christopher b006fc9c07 Rewrite stack callee saved spills and restores to use push/pop instructions.
Remove movePastCSLoadStoreOps and associated code for simple pointer
increments. Update routines that depended upon other opcodes for save/restore.

Adjust all testcases accordingly.

llvm-svn: 119725
2010-11-18 19:40:05 +00:00
Chris Lattner 3ddef1ac36 silence a ton of warnings from clang.
llvm-svn: 119102
2010-11-15 01:45:44 +00:00
Anton Korobeynikov f7183edb59 First step of huge frame-related refactoring: move emit{Prologue,Epilogue} out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place
llvm-svn: 119097
2010-11-15 00:06:54 +00:00
Eric Christopher b90f7004cf Revert this temporarily.
llvm-svn: 118827
2010-11-11 19:47:02 +00:00
Eric Christopher e6283f950d Change the prologue and epilogue to use push/pop for the low ARM registers.
llvm-svn: 118823
2010-11-11 19:26:03 +00:00
Jim Grosbach 40e85fbf17 move getRegisterNumbering() to out of ARMBaseRegisterInfo into the helper
functions in ARMBaseInfo.h so it can be used in the MC library as well.
For anything bigger than this, we may want a means to have a small support
library for shared helper functions like this. Cross that bridge when we
come to it.

llvm-svn: 114016
2010-09-15 20:26:25 +00:00
Jim Grosbach 9569567255 simplify getRegisterNumbering(). Remove the unused isSPVFP argument and
merge the common cases.

llvm-svn: 114013
2010-09-15 19:52:17 +00:00
Jim Grosbach 03f4be86ba Re-apply r112883:
"For ARM stack frames that utilize variable sized objects and have either
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs."

r112986 fixed a latent bug exposed by the above.

llvm-svn: 112989
2010-09-03 18:37:12 +00:00
Daniel Dunbar 2ac3386ef3 Revert "For ARM stack frames that utilize variable sized objects and have either", it is breaking oggenc with Clang for ARMv6.
This reverts commit 8d6e29cfda270be483abf638850311670829ee65.

llvm-svn: 112962
2010-09-03 15:26:42 +00:00
Jim Grosbach 7fd9aea67c For ARM stack frames that utilize variable sized objects and have either
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs.

rdar://7352504
rdar://8374540
rdar://8355680

llvm-svn: 112883
2010-09-02 22:29:01 +00:00
Jim Grosbach 6a77066913 Simplify eliminateFrameIndex() interface back down now that PEI doesn't need
to try to re-use scavenged frame index reference registers. rdar://8277890

llvm-svn: 112241
2010-08-26 23:32:16 +00:00
Jim Grosbach e82d5b4aaf tidy up a bit. no functional change.
llvm-svn: 112228
2010-08-26 21:56:30 +00:00
Jim Grosbach 2eedb7949e Add ARM heuristic for when to allocate a virtual base register for stack
access. rdar://8277890&7352504

llvm-svn: 111968
2010-08-24 21:19:33 +00:00
Jim Grosbach b77d67f318 Move enabling the local stack allocation pass into the target where it belongs.
For now it's still a command line option, but the interface to the generic
code doesn't need to know that.

llvm-svn: 111942
2010-08-24 19:05:43 +00:00
Jim Grosbach 56e56323c8 Better handling of offsets on frame index references. rdar://8277890
llvm-svn: 111585
2010-08-19 23:52:25 +00:00
Jim Grosbach e0e9b3013f Add hook for re-using virtual base registers for local stack slot access.
Nothing fancy, just ask the target if any currently available base reg
is in range for the instruction under consideration and use the first one
that is. Placeholder ARM implementation simply returns false for now.

ongoing saga of rdar://8277890

llvm-svn: 111374
2010-08-18 17:57:37 +00:00
Jim Grosbach 3cf08661f4 Add materialization of virtual base registers for frame indices allocated into
the local block. Resolve references to those indices to a new base register.
For simplification and testing purposes, a new virtual base register is
allocated for each frame index being resolved. The result is truly horrible,
but correct, code that's good for exercising the new code paths.

Next up is adding thumb1 support, which should be very simple. Following that
will be adding base register re-use and implementing a reasonable ARM
heuristic for when a virtual base register should be generated at all.

llvm-svn: 111315
2010-08-17 22:41:55 +00:00
Jim Grosbach c252ee2375 Add hook to examine an instruction referencing a frame index to determine
whether to allocate a virtual frame base register to resolve the frame
index reference in it. Implement a simple version for ARM to aid debugging.

In LocalStackSlotAllocation, scan the function for frame index references
to local frame indices and ask the target whether to allocate virtual
frame base registers for any it encounters. Purely infrastructural for
debug output. Next step is to actually allocate base registers, then add
intelligent re-use of them.

rdar://8277890

llvm-svn: 111262
2010-08-17 18:13:53 +00:00
Jim Grosbach f50693d1ab For local variables in functions with a frame pointer, use FP as a base
register for local access when it's closer to the stack slot being refererenced
than the stack pointer. Make sure to take into account any argument frame
SP adjustments that are in affect at the time.

rdar://8256090

llvm-svn: 110366
2010-08-05 19:27:37 +00:00
Chris Lattner cbe9856fce prune #includes a little.
llvm-svn: 108929
2010-07-20 21:17:29 +00:00
Eric Christopher 4adaccf0bf Constify some arguments.
llvm-svn: 108812
2010-07-20 06:52:21 +00:00
Jim Grosbach 84511e1526 Clean up 80 column violations. No functional change.
llvm-svn: 105350
2010-06-02 21:53:11 +00:00
Bob Wilson 2d35a9e810 Rename canCombinedSubRegIndex method to something more grammatically correct
and tidy up the comment describing it.

llvm-svn: 105339
2010-06-02 18:54:47 +00:00
Rafael Espindola 94801a47f8 Replace ARM's getCalleeSavedRegClasses with a simpler solution
llvm-svn: 105335
2010-06-02 17:54:50 +00:00
Evan Cheng 8c2d062ea6 Teach two-address pass to do some coalescing while eliminating REG_SEQUENCE
instructions.

e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12

After REG_SEQUENCE is eliminated, we are left with:

%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5

The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible, 
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.

llvm-svn: 103835
2010-05-14 23:21:14 +00:00
Jim Grosbach fae913adf8 Change the Value argument to eliminateFrameIndex to a type-tagged value. This
is preparatory to having PEI's scavenged frame index value reuse logic
properly distinguish types of frame values (e.g., whether the value is
stack-pointer relative or frame-pointer relative).

No functionality change.

llvm-svn: 98086
2010-03-09 21:45:49 +00:00
Jim Grosbach 45fceea0e4 Updated version of r96634 (which was reverted due to failing 176.gcc and
126.gcc nightly tests. These failures uncovered latent bugs that machine DCE
could remove one half of a stack adjust down/up pair, causing PEI to assert.
This update fixes that, and the tests now pass.

llvm-svn: 96822
2010-02-22 23:10:38 +00:00
Bob Wilson fbc9d8d424 Revert 96634. It causes assertion failures for 126.gcc and 176.gcc in
the armv6 nightly tests.

llvm-svn: 96691
2010-02-19 18:59:53 +00:00