| Message ID | 001d01d87428$58e9c9a0$0abd5ce0$@nextmovesoftware.com |
|---|---|
| State | New |
| Headers | show |
| Series | [x86] Allow SCmode and DImode to be tieable on TARGET_64BIT. | expand |
On Mon, May 30, 2022 at 3:22 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > This patch is a form of insurance policy in case my patch for PR 7061 runs > into problems on non-x86 targets; the middle-end can add an extra check > that the backend is happy placing SCmode and DImode values in the same > register, before creating a SUBREG. Unfortunately, ix86_modes_tieable_p > currently claims this is not allowed(?), even though the default target > hook for modes_tieable_p is to always return true [i.e. false can be > used to specifically prohibit bad combinations], and the x86_64 ABI > passes SCmode values in DImode registers!. This makes the backend's > modes_tiable_p hook a little more forgiving, and additionally enables > interconversion between SCmode and V2SFmode, and between DCmode and > VD2Fmode, which opens interesting opportunities in the future. > > I believe there should currently be no code generation differences > with this change. This patch has been tested on x86_64-pc-linux-gnu > with make bootstrap and make -k check, both with and without > --target_board=unix{-m32}, with no new failures. Ok for mainline? > > > 2022-05-30 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > * config/i386/i386.cc (ix86_modes_tieable_p): Allow SCmode to be > tieable with DImode on TARGET_64BIT, and SCmode tieable with > V2SFmode, and DCmode with V2DFmode. I *think* this is OK, but hard to say for sure without some testcases. Please note that x86_64 ABI passes SDmode in two separate XMM registers. Uros.
On Mon, May 30, 2022 at 10:12 PM Uros Bizjak <ubizjak@gmail.com> wrote: > > On Mon, May 30, 2022 at 3:22 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > > > > This patch is a form of insurance policy in case my patch for PR 7061 runs > > into problems on non-x86 targets; the middle-end can add an extra check > > that the backend is happy placing SCmode and DImode values in the same > > register, before creating a SUBREG. Unfortunately, ix86_modes_tieable_p > > currently claims this is not allowed(?), even though the default target > > hook for modes_tieable_p is to always return true [i.e. false can be > > used to specifically prohibit bad combinations], and the x86_64 ABI > > passes SCmode values in DImode registers!. This makes the backend's > > modes_tiable_p hook a little more forgiving, and additionally enables > > interconversion between SCmode and V2SFmode, and between DCmode and > > VD2Fmode, which opens interesting opportunities in the future. > > > > I believe there should currently be no code generation differences > > with this change. This patch has been tested on x86_64-pc-linux-gnu > > with make bootstrap and make -k check, both with and without > > --target_board=unix{-m32}, with no new failures. Ok for mainline? > > > > > > 2022-05-30 Roger Sayle <roger@nextmovesoftware.com> > > > > gcc/ChangeLog > > * config/i386/i386.cc (ix86_modes_tieable_p): Allow SCmode to be > > tieable with DImode on TARGET_64BIT, and SCmode tieable with > > V2SFmode, and DCmode with V2DFmode. > > I *think* this is OK, but hard to say for sure without some testcases. > Please note that x86_64 ABI passes SDmode in two separate XMM > registers. I meant DCmode here. Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index daa60ac..df5c80d 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -20141,6 +20141,18 @@ ix86_modes_tieable_p (machine_mode mode1, machine_mode mode2) return (GET_MODE_SIZE (mode1) == 8 && ix86_hard_regno_mode_ok (FIRST_MMX_REG, mode1)); + /* SCmode and DImode can be tied. */ + if ((mode1 == E_SCmode && mode2 == E_DImode) + || (mode1 == E_DImode && mode2 == E_SCmode)) + return TARGET_64BIT; + + /* [SD]Cmode and V2[SD]Fmode modes can be tied. */ + if ((mode1 == E_SCmode && mode2 == E_V2SFmode) + || (mode1 == E_V2SFmode && mode2 == E_SCmode) + || (mode1 == E_DCmode && mode2 == E_V2DFmode) + || (mode1 == E_V2DFmode && mode2 == E_DCmode)) + return true; + return false; }
This patch is a form of insurance policy in case my patch for PR 7061 runs into problems on non-x86 targets; the middle-end can add an extra check that the backend is happy placing SCmode and DImode values in the same register, before creating a SUBREG. Unfortunately, ix86_modes_tieable_p currently claims this is not allowed(?), even though the default target hook for modes_tieable_p is to always return true [i.e. false can be used to specifically prohibit bad combinations], and the x86_64 ABI passes SCmode values in DImode registers!. This makes the backend's modes_tiable_p hook a little more forgiving, and additionally enables interconversion between SCmode and V2SFmode, and between DCmode and VD2Fmode, which opens interesting opportunities in the future. I believe there should currently be no code generation differences with this change. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=unix{-m32}, with no new failures. Ok for mainline? 2022-05-30 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * config/i386/i386.cc (ix86_modes_tieable_p): Allow SCmode to be tieable with DImode on TARGET_64BIT, and SCmode tieable with V2SFmode, and DCmode with V2DFmode. Thanks in advance, Roger --