Adam Nemet <ane...@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
