summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
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
commitf6bae1e434dd42b06f711f8b6652ec4173a8097c (patch)
tree4954a359181db906f457af1f2d6ab2f1b6fb5017 /llvm/lib/Support
parent1d959008d664cf6dcc0bb424f228421696d82586 (diff)
downloadbcm5719-llvm-f6bae1e434dd42b06f711f8b6652ec4173a8097c.tar.gz
bcm5719-llvm-f6bae1e434dd42b06f711f8b6652ec4173a8097c.zip
[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. llvm-svn: 185434
Diffstat (limited to 'llvm/lib/Support')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud