> > Here we do have a hard register, but it isn't valid to form the subreg > > on that hard register. Reload had to cope with that case too. > > > > Since the subreg on the original hard register is invalid, we can't use > > it to decide whether the intention was to write to only a part of the > > inner register. But I don't think we need to use the hard register > > here. The original register was a psuedo and I'm pretty sure...
Indeed, it is a hard register (64 IIRC) since get_try_hard_regno () must return >= 0. > > > The differences (hard vs pseudo regs) are primarily an implementation > > > detail. I was really looking to see if there was existing code which > > > would turn an output reload into an in-out reload for these subregs. > > > > > > The in-out nature of certain subregs is something I've personally > > > stumbled over in various contexts (for example, this also came up > > > during RTL-SSA investigations years ago). > > > > ...the rule for pseudos is that words of a multiword pseudo can be > > accessed independently but subword pieces of an individual word can't. > > This obviously isn't ideal if a mode is intended for wider-than-word > > registers, since not all words will be independently addressable when > > allocated to those registers. The code above is partly dealing with the > > fallout from that. It's also why we have strict_lowpart for cases like > > al on i386. > > > > So IMO the patch is too broad. I think it should only use INOUT reloads > > for !strict_low if the inner mode is wider than a word and the outer > > mode is strictly narrower than the inner mode. That's on top of Vlad's > > comment about only converting OP_OUTs, of course. > > This sounds correct/sensible. The change as committed will be turning > some OP_OUT reloads into OP_INOUT unnecessarily. Checking for !strict_low > is however probably redundant as strict_low must be OP_INOUT and never > OP_OUT but we could mask backend bugs by converting strict_low subregs. > > I think this should be resolved for GCC 5 if others agree it is an issue. > > Matthew This makes sense since we've got the inner wider than a word and I agree it'd be better to resolve this for GCC 5. Robert
