diff options
| author | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-07-02 15:28:56 +0000 |
|---|---|---|
| committer | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-07-02 15:28:56 +0000 |
| commit | 1ce4894a3f1ce6e63c1b109c24235d81dea2908f (patch) | |
| tree | 60dc3250ee6c3f68f37ff3e6dadd9a3bae7cabdb /docs/CommandGuide/llvm-extract.rst | |
| parent | 9188443a2d35352c4e8a2cffd1b4d31d47843b26 (diff) | |
| download | external_llvm-1ce4894a3f1ce6e63c1b109c24235d81dea2908f.zip external_llvm-1ce4894a3f1ce6e63c1b109c24235d81dea2908f.tar.gz external_llvm-1ce4894a3f1ce6e63c1b109c24235d81dea2908f.tar.bz2 | |
[SystemZ] Use MVC to spill loads and stores
Try to use MVC when spilling the destination of a simple load or the source
of a simple store. As explained in the comment, this doesn't yet handle
the case where the load or store location is also a frame index, since
that could lead to two simultaneous scavenger spills, something the
backend can't handle yet. spill-02.py tests that this restriction kicks in,
but unfortunately I've not yet found a case that would fail without it.
The volatile trick I used for other scavenger tests doesn't work here
because we can't use MVC for volatile accesses anyway.
I'm planning on relaxing the restriction later, hopefully with a test
that does trigger the problem...
Tests @f8 and @f9 also showed that L(G)RL and ST(G)RL were wrongly
classified as SimpleBDX{Load,Store}. It wouldn't be easy to test for
that bug separately, which is why I didn't split out the fix as a
separate patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185434 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/CommandGuide/llvm-extract.rst')
0 files changed, 0 insertions, 0 deletions
