"Robin Dapp" <[email protected]> writes:
>> Could be, but even if it's not: OImode is easy. We can just split
>> into
>> TImode bits and those would work. Target-independent code doesn't have
>> the quandry that it had with TImode.
>
> As expected, with separate target expanders and dedicated spill code for
> affected subregs, things fall into their place.
Do you mean that you add OImode patterns? I don't think that should
be necessary. Like I say, I think it'd be reasonable for emit_move_insn
to split into TImode pieces.
I can try to have a go at that in the next week or two.
> There's just one ICE
> from before left in simplify_subreg_concatn (gcc.dg/pr44136.c). It can
> be fixed by:
>
> @@ -762,6 +779,10 @@ resolve_subreg_p (rtx x)
> {
> if (GET_CODE (x) != SUBREG)
> return false;
> + /* We can only resolve the subreg if it is splittable. */
> + if (maybe_lt ((unsigned) UNITS_PER_WORD,
> + (poly_uint64) REGMODE_NATURAL_SIZE (GET_MODE (x))))
> + return false;
> return resolve_reg_p (SUBREG_REG (x));
> }
>
> Is that reasonable on top of what we converged on? (Bootstrap, regtest
> look good) If so, I'll send out the new version, maybe CC'ing Tamar for
> the aarch64 bits.
That doesn't look right. The CONCATNs are generated by the pass itself
and can't be left as-is. The failure path for !resolve_subreg_p is
also different from the failure path for !simplify_subreg_concatn.
So it feels like the problem is elsewhere to me.
Richard
