Re: Rationale for an old TRUNCATE patch

[Ian Lance Taylor <iant at google dot com>]

Adam Nemet <anemet@caviumnetworks.com> writes:

> Ian Lance Taylor writes:
>> I agree that this patch looks wrong in todays compiler.  There should be
>> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.
>
> Thanks.
>
> Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
> TRUNCATEs?

truncate has a machine independent meaning.

> I can't think of why it would be useful to represent a mode so that bits
> outside the mode mask don't either depent on bits inside the mask or are
> don't-care bits.  IOW, can we assume that for any TRUNCATE from wider mode W
> to narrower mode N the following holds:
>
>   (truncate:N expr:W) == (truncate:N (and:W expr:W GET_MODE_MASK(Nmode)))
>
> ?  Where == is not necessarily identical bit representation of the object
> holding the value (e.g. QI HI values in MIPS) but that they are
> indistinguishable in the operations that are defined on them.

Yes.  The bits in Nmode's mask are determined by the truncate.  The
other bits are don't-care.  If the result of the truncate happens to
wind up in a register, then in some cases PROMOTE_MODE will apply.

Ian