On Thu, Feb 11, 2016 at 07:38:15PM +0100, Ulrich Weigand wrote: > For the most part, this patch doesn't really change anything in the > interaction with reload as far as I can see. The changes introduced > by the patch do make sense to me. In particular, replacing the two > patterns p8_mtvsrd_1 and p8_mtvsrd_2 used to fill high and low parts > of a TFmode register pair with a single pattern p8_mtvsrd that just > works on any DFmode register (leaving the split into high/low to the > caller if necessary) seems to simplify things. > > > > + /* You might think that we could use op0 as one temp and a DF clobber > > > + as the other, but you'd be wrong. These secondary_reload patterns > > > + don't check that the clobber is different to the destination, which > > > + is probably a reload bug. */ > > It's not a bug, it's deliberate behavior. The reload registers allocated > for secondary reload clobbers may overlap the destination, since in many > cases you simply move the input to the reload register, and then the > reload register to the destination (where the latter move can be a no-op > if it is possible to allocate the reload register and the destination > into the same physical register). If you need two separate intermediate > values, you need to allocate a secondary reload register of a larger > mode (as is already done in the pattern).
This is one of the cases I wished the reload support had the ability to allocate 2 scratch temporaries instead of 1. As I said in my other message, TFmode was a hack to get two registers to use. > While this was not introduced by this patch, I'm a little bit concerned > about the hard-coded use of REGNO here, which will crash if op0 at this > point happens to be a SUBREG instead of a REG. This is extremely unlikely > at this point in reload, but not 100% impossible, e.g. if op0 for some > reason is one of the "magic" registers like the stack pointer. > > That's why it is in general better to use simplify_gen_subreg or one of > gen_highpart/gen_lowpart, which will handle SUBREG correctly as well. > I'm not sure why it matters whether this is "conceptually a separate > value" as the comment argues ... Good catch. -- 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
