On Thu, Feb 11, 2016 at 09:34:29AM -0800, David Edelsohn wrote: > On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra <amo...@gmail.com> wrote: > > This is PR68973 part 2, the failure of a boost test, caused by a > > splitter emitting an invalid move in reload_vsx_from_gprsf: > > emit_move_insn (op0_di, op2); > > > > op0 can be any vsx reg, but the mtvsrd destination constraint in > > movdi_internal64 is "wj", which only allows fp regs. I'm not sure why > > we have that constraint so left movdi_internal64 alone and used a > > special p8_mtvsrd instead, similar to p8_mtvsrd_1 and p8_mtvsrd_2 used > > by reload_vsx_from_gpr<mode>. When looking at those, I noticed we're > > restricted to fprs there too so fixed that as well. (We can't use %L > > in asm operands that must accept vsx.) > > Michael, please review the "wj" constraint in these patterns. > > Alan, the explanation says that it uses a special p8_mtvsrd similar to > p8_mtvsrd_[12], but does not explain why the two similar patterns are > removed. The incorrect use of %L implies those patterns, but the > change is to p8_xxpermdi_<mode> that is not mentioned in the > ChangeLog. > > I also would appreciate Uli's comments on this direction because of > his reload expertise.
Since the mail was sent to my Lotus Notes account (mrmei...@us.ibm.com), I originally tried to reply through that system, but I got bounce errors. At the present time, we do not allow DImode to go into Altivec registers. Mostly it was due to reload complications in the power8 time frame, where we didn't have d-form addressing for the Altivec registers and interference with the other DImode reload patterns, but also I felt I would need to go through the main rs6000.md to look for the various DImode patterns to see if they needed to be updated. At some I hoped to extend this, so I added the "wi" and "wj" constraints to be used whenever the mode is DImode. "wi" is the constraint for the VSX register class DImode can go in (i.e. currently FLOAT=5FREGS), and "wj" is the VSX register class DImode can go in if we have 64-bit direct move. The TFmode thing was a hack. It was the only way I could see getting two registers without a lot of hair. Since TFmode is also restricted to FPR_REGS, you could use %L on it. When I was writing it, I really wished we had a reload pattern to get more than one temporary, but we didn't, so I went for TFmode to get 2 FPR registers. Given the replacement pattern no longer uses a TFmode temporary, it can go in any appropriate register. If you are using DFmode, the right constraint is "wk" (appropriate register to use with the double type when direct moves are available) or "ws" (appropriate register to use for DFtype with VSX instructions). We don't have a constraint for appropriate register class to use with SFmode when direct moves are available, so I would suggest using "wy" for a register class you can use ISA 2.07 (power8) ops (the float scalar ops in the upper registers). The "ww" constraint would be the appropriate register to use ISA 2.06 (power7) operations on SFmode. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
