Alan Modra wrote: > On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote: > > 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.
Hmm, OK. That does make things simpler. > > 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. I was thinking here that in the special case of the *reload scratch register*, which reload allocates for us, we will always get a full register. This is different from some other operand that may originate from pre-existing RTX that may require a SUBREG even after reload. But I certainly agree that your current patch looks like a good choice for a stage4 bugfix change. Further cleanup can always happen later. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
