> I think modelling it as a TRUNCATE operation is correct for > !TRULY_NOOP_TRUNCATION (it's the bug that Andrew pointed out). > And we shouldn't generate an actual TRUNCATE rtx for > TRULY_NOOP_TRUNCATION (the thing about making > simplify_gen_unary (TRUNCATE, ...) no worse than simplify_gen_subreg > for those targets). I suppose: > > /* We can't handle truncation to a partial integer mode here > because we don't know the real bitsize of the partial > integer mode. */ > if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) > break; > > might be a problem though; we should still allow a subreg to be > generated. Is that what you were thinking of, or something else?
I was thinking of the !TRULY_NOOP_TRUNCATION case, where the two operations aren't equivalent. Generating TRUNCATE in simplify_subreg seems suspicious to me in this case but, if not doing it is the source of the bug, I guess I need to do some homework on this TRULY_NOOP_TRUNCATION stuff. :-) Maybe add a blurb to the head comment of simplify_truncation, explaining that it is valid to call the function both for TRUNCATEs and truncations to the lowpart, and why it is correct to generate new TRUNCATEs in the latter case. -- Eric Botcazou
