[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.