http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #17 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- I'm just saying this for the record, and also to justify why I think the other use of simplify_gen_subreg is correct. (In reply to Michael Meissner from comment #14) > When you are doing a subreg type operation, before reload, you must NOT use > the > register number directly. This is the dangerous part that was mentioned. David was quoting me with the dangerous thing, so for what it's worth, I meant that it would be dangerous to have a version of simplify_gen_subreg that ignored CANNOT_CHANGE_MODE_CLASS. And as long as simplify_gen_subreg honours CANNOT_CHANGE_MODE_CLASS, a DImode subreg of an SFmode FPR is going to return a subreg rather than a plain reg. I definitely agree that using gen_rtx_REG before reload is dangerous too of course. I just wanted to clarify what I meant. > Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the > appropriate solution. Agreed, > If you are doing splits after reload, and are dealing with whole registers, > the > preferred solution is to create a new REG with the appropriate register > number. > In particular, gen_highpart and gen_lowpart must not be used after reload. > However, up until the patch to add more checking, simplify_gen_subreg could be > used after reload. FWIW, I think gen_lowpart, gen_highpart and simplify_gen_subreg are always OK if what you are doing is changing the mode of a value. They are supposed to handle both hard and pseudo registers. So I think the other use of simplify_gen_subreg in this pattern is OK (and gen_lowpart would be have been OK too). Using gen_rtx_REG wouldn't be wrong as such, but it would lose things like ORIGINAL_REGNO. The difference here is that we have a DImode temporary value and an SFmode result that both need the same hard register. The DImode value is written and read only in DImode and the result is written only in SFmode, so there's no real mode change. That's the kind of case where gen_rtx_REG is needed. > Out of force of habit, I've tended to use simplify_gen_subreg when doing > splitting, no matter whether it is before or after reload. I thought with > 'simplify' in the name, it would do the right thing after reload, but > evidently > it does not. Well, I suppose it depends on what the expectations are. If the target forbids a particular mode change for a particular hard register, simplify_gen_subreg will return a subreg rather than a reg. IMO that's the right thing to do, since it keeps the information that you have a mode change that can't be reduced to a plain reg. Returning null would be another option (maybe better) but would probably have a big impact. So I think the problem in this case was that we were modelling the reuse of the destination register as a mode change when it wasn't really, and the mode change in question was one that the target normally tries to prevent.
