On Mon, Feb 15, 2016 at 4:36 AM, Alan Modra <amo...@gmail.com> wrote: > On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote: >> > On Fri, Feb 12, 2016 at 08:54:19AM +1030, Alan Modra wrote: >> > > Another concern I had about this, besides using %L in asm output (what >> > > forces TFmode to use just fprs?), is what happens when we're using >> > > IEEE 128-bit floats? In that case it looks like we'd get just one reg. >> > >> > Good point that it breaks if the default long double (TFmode) type is IEEE >> > 128-bit floating point. We would need to have two patterns, one that uses >> > TFmode and one that uses IFmode. I wrote the power8 direct move stuff >> > before >> > going down the road of IEEE 128-bit floating point. >> >> Right. It's a bit unfortunate that we can't just use IFmode unconditionally, >> but it seems rs6000_scalar_mode_supported_p (IFmode) may return false, and >> then we probably shouldn't be using it. > > Actually, we can use IFmode unconditionally. scalar_mode_supported_p > is relevant only up to and including expand. Nothing prevents the > backend from using IFmode. > >> Another option might be to use TDmode to allocate a scratch register pair. > > That won't work, at least if we want to extract the two component regs > with simplify_gen_subreg, due to rs6000_cannot_change_mode_class. In > my original patch I just extracted the regs by using gen_rtx_REG but I > changed that, based on your criticism of using gen_rtx_REG in > reload_vsx_from_gprsf, and because rs6000.md avoids gen_rtx_REG using > operand regnos in other places. That particular change is of course > entirely cosmetic. I also changed reload_vsx_from_gprsf to avoid mode > punning regs, instead duplicating insn patterns as done elsewhere in > the vsx support. I don't believe we will see subregs of vsx or fp > regs after reload, but I'm quite willing to concede the point for a > stage4 fix. > > Here's the revised patch. To recap, the main bug fixes here are: > - stop reload_vsx_from_gprsf splitter from emitting a move not > handled by movdi_internal64 > - don't use TFmode, which cannot now be assumed to be IBM > double-double. > Secondary to that, not using or passing around TFmode means the %L > restriction no longer matters, and constraints on the reload temp reg > can be relaxed. > > Bootstrapped and regression tested powerpc64-linux biarch and > powerpc64le-linux. OK David? > > PR target/68973 > * config/rs6000/rs6000.md (reload_vsx_from_gprsf): Use p8_mtvsrd_sf > rather than attempting to use movdi_internal64. Remove op0_di. > (p8_mtvsrd_df, p8_mtvsrd_sf): New. > (p8_mtvsrd_1, p8_mtvsrd_2): Delete. > (p8_mtvsrwz): New. > (p8_mtvsrwz_1, p8_mtvsrwz_2): Delete. > (p8_xxpermdi_<mode>): Take two DF inputs rather than one TF. > (p8_fmrgow_<mode>): Likewise. > (reload_vsx_from_gpr<mode>): Make clobber IF. Adjust for above > changes. > (reload_fpr_from_gpr<mode>): Similarly. Use "d" for op0 constraint. > * config/rs6000/vsx.md (vsx_xscvspdpn_directmove): Make op1 SFmode. >
Okay. Is there still an issue with the constraints used for movdi_internal64? Thanks, David
