aboutsummaryrefslogtreecommitdiffstats
path: root/docs/CommandGuide/bugpoint.rst
diff options
context:
space:
mode:
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-07-02 15:28:56 +0000
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-07-02 15:28:56 +0000
commit1ce4894a3f1ce6e63c1b109c24235d81dea2908f (patch)
tree60dc3250ee6c3f68f37ff3e6dadd9a3bae7cabdb /docs/CommandGuide/bugpoint.rst
parent9188443a2d35352c4e8a2cffd1b4d31d47843b26 (diff)
downloadexternal_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/bugpoint.rst')
0 files changed, 0 insertions, 0 deletions