diff options
| author | krebbel <krebbel@138bc75d-0d04-0410-961f-82ee72b054a4> | 2016-04-20 07:13:23 +0000 |
|---|---|---|
| committer | krebbel <krebbel@138bc75d-0d04-0410-961f-82ee72b054a4> | 2016-04-20 07:13:23 +0000 |
| commit | 5453043757c95bef5b3a32c579cd5e9826d6aad2 (patch) | |
| tree | 6173dc8b27fe3bd23e45989366037df9723eb16a /gcc/ChangeLog | |
| parent | 6ca2913460d1e49051b1e63431b11acf8efbe8f0 (diff) | |
| download | gcc-5453043757c95bef5b3a32c579cd5e9826d6aad2.tar.gz | |
PR70674: S/390: Add memory barrier to stack pointer restore from fpr.
This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions. In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.
The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn. The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other. The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.
With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn. The patch does that only for the one case
where the stack pointer is restored from an FPR. Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple. However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well. So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.
Another case which needs to be handled some day is the stack pointer
allocation part. It needs to be a memory barrier as well.
Bootstrapped and regression tested with --with-arch z196 and z13 on
s390 and s390x.
-Andreas-
gcc/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel@linux.vnet.ibm.com>
PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR. Compared to
the normal move insn this pattern includes a full memory barrier.
gcc/testsuite/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel@linux.vnet.ibm.com>
PR target/70674
* gcc.target/s390/pr70674.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235234 138bc75d-0d04-0410-961f-82ee72b054a4
Diffstat (limited to 'gcc/ChangeLog')
| -rw-r--r-- | gcc/ChangeLog | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 30da178049a..685aba31ccb 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,14 @@ +2016-04-20 Andreas Krebbel <krebbel@linux.vnet.ibm.com> + + PR target/70674 + * config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new + stack_restore_from_fpr pattern when restoring r15. + (s390_optimize_prologue): Strip away the memory barrier in the + parallel when trying to get rid of restore insns. + * config/s390/s390.md ("stack_restore_from_fpr"): New insn + definition for loading the stack pointer from an FPR. Compared to + the normal move insn this pattern includes a full memory barrier. + 2016-04-19 Jakub Jelinek <jakub@redhat.com> PR middle-end/70680 |