aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree.c
diff options
context:
space:
mode:
authorJeff Law <law@redhat.com>2020-03-25 10:37:31 -0600
committerJeff Law <law@redhat.com>2020-03-25 10:37:31 -0600
commit713ecb3d417363a4b12c725b335fce10355da206 (patch)
tree1e9b1629c0cd19232bdaca4a799e78fd76d0cfeb /gcc/tree.c
parentc7a252ba2d0a08397d8fc6d6dc7db34f90f76acb (diff)
downloadgcc-713ecb3d417363a4b12c725b335fce10355da206.zip
gcc-713ecb3d417363a4b12c725b335fce10355da206.tar.gz
gcc-713ecb3d417363a4b12c725b335fce10355da206.tar.bz2
rs6000: Allow FPRs to change between SDmode and DDmode [PR94254]
g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle on some SDmode reloads for power6. As explained in more detail in the PR comments, the problem was a conflict between two target hooks: rs6000_secondary_memory_needed_mode required SDmode FPR reloads to use DDmode memory (rightly, since using SDmode memory wouldn't make progress) but rs6000_can_change_mode_class didn't allow FPRs to change from SDmode to DDmode. Previously lra ignored that and changed the mode anyway. From what Segher says, it sounds like the "from_size < 8 || to_size < 8" check is mostly there for SF<->64-bit subregs, and that SDmode is stored in the way that target-independent code expects. This patch therefore allows SD<->DD changes. I wondered about checking for SD<->64-bit changes instead, but that seemed like an unnecessary generalisation for this stage. 2020-03-23 Richard Sandiford <richard.sandiford@arm.com> gcc/ PR target/94254 * config/rs6000/rs6000.c (rs6000_can_change_mode_class): Allow FPRs to change between SDmode and DDmode.
Diffstat (limited to 'gcc/tree.c')
0 files changed, 0 insertions, 0 deletions