This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rationale for an old TRUNCATE patch


Ian Lance Taylor wrote:
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.
Based on reviewing my old notes, we do have to ensure that combine doesn't replace a TRUNCATE with a SUBREG as that can result in having a 32bit value that isn't sign-extended, which clearly causes MIPS64 ports grief.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]