| Message ID | 6D39441BF12EF246A7ABCE6654B0235380B5CE9A@hhmail02.hh.imgtec.org |
|---|---|
| State | New |
| Headers | show |
On 02/07/2017 09:08 AM, Matthew Fortune wrote: > Hi, > > This patch addresses a problem with LRA splitting hard registers > where the mode requires multiple registers. When splitting then > each constituent register is split individually using the widest > mode for each register but no check is made that such a mode is > actually supported in those registers. > > MIPS has an ABI variant o32 FPXX that allows DFmode values to > exist in pairs of 32-bit floating point registers but only the > first 32-bit register is directly addressable. The second > register can only be accessed as part of a 64-bit load/store or > via a special move instruction used as part of a 64-bit move. > > The split is simply rejected to ensure compliance with the ABI > although I expect the split logic could account for this case > and split using the wider mode. Such a change appears more > invasive than appropriate in stage 4. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 > > It is unknown if any other LRA enabled target could hit this > issue but it is certainly possible depending on mode/register > restrictions. The patch is ok for the trunk and it is pretty safe. Thank you Robert and Matt.
Vladimir Makarov <vmakarov@redhat.com> writes: > On 02/07/2017 09:08 AM, Matthew Fortune wrote: > > Hi, > > > > This patch addresses a problem with LRA splitting hard registers where > > the mode requires multiple registers. When splitting then each > > constituent register is split individually using the widest mode for > > each register but no check is made that such a mode is actually > > supported in those registers. > > > > MIPS has an ABI variant o32 FPXX that allows DFmode values to exist in > > pairs of 32-bit floating point registers but only the first 32-bit > > register is directly addressable. The second register can only be > > accessed as part of a 64-bit load/store or via a special move > > instruction used as part of a 64-bit move. > > > > The split is simply rejected to ensure compliance with the ABI > > although I expect the split logic could account for this case and > > split using the wider mode. Such a change appears more invasive than > > appropriate in stage 4. > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 > > > > It is unknown if any other LRA enabled target could hit this issue but > > it is certainly possible depending on mode/register restrictions. > The patch is ok for the trunk and it is pretty safe. Thank you Robert > and Matt. Committed as r245601. Thanks, Matthew
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c index 0b7ae34..db6e878 100644 --- a/gcc/lra-constraints.c +++ b/gcc/lra-constraints.c @@ -5402,6 +5402,26 @@ split_reg (bool before_p, int original_regno, rtx_insn *insn, } return false; } + /* Split_if_necessary can split hard registers used as part of a + multi-register mode but splits each register individually. The + mode used for each independent register may not be supported + so reject the split. Splitting the wider mode should theoretically + be possible but is not implemented. */ + if (! HARD_REGNO_MODE_OK (hard_regno, mode)) + { + if (lra_dump_file != NULL) + { + fprintf (lra_dump_file, + " Rejecting split of %d(%s): unsuitable mode %s\n", + original_regno, + reg_class_names[lra_get_allocno_class (original_regno)], + GET_MODE_NAME (mode)); + fprintf + (lra_dump_file, + " ))))))))))))))))))))))))))))))))))))))))))))))))\n"); + } + return false; + } new_reg = lra_create_new_reg (mode, original_reg, rclass, "split"); reg_renumber[REGNO (new_reg)] = hard_regno; }