Re: Rationale for an old TRUNCATE patch

[Ian Lance Taylor <iant@google.com>]

Adam Nemet <anemet@caviumnetworks.com> writes:

> I am trying to understand the checkin by Jeff Law from about 11 years ago:
>
>    r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
>    
>    
>            * combine.c (simplify_rtx, case TRUNCATE): Respect value of
>            TRULY_NOOP_TRUNCATION.
>    
>    
>    Index: combine.c
>    ===================================================================
>    --- combine.c	(revision 19018)
>    +++ combine.c	(revision 19204)
>    @@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest
>           if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)
>     	break;
>     
>    -      if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
>    +      if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT
>    +	  && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
>    +				    GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0)))))
>     	SUBST (XEXP (x, 0),
>     	       force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)),
>     			      GET_MODE_MASK (mode), NULL_RTX, 0));
>
> This optimization simplifies the input to a truncate by only computing bits
> that won't be eliminated by the truncation.  Normally these are the bits in
> the output mode mask.  Note that the optimization does not change the truncate
> into a low-part subreg, which would pretty automatically warrant the
> TRULY_NOOP_TRUNCATION check.

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.


> Specifically I am curious if this was prompted by MIPS (or SH) or maybe some
> other target that have a notion of truncate different from MIPS.

It pretty much has to have been MIPS or SH since I don't think any other
target back then defined TRULY_NOOP_TRUNCATION as anything other than 1.

Ian