On Mon, May 30, 2022 at 10:12 PM Uros Bizjak <ubiz...@gmail.com> wrote:
>
> On Mon, May 30, 2022 at 3:22 PM Roger Sayle <ro...@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 <ro...@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.
