Re: paradoxical subreg problem [ patch attached ]

[law at redhat dot com]

 In message <10201291701.AA00502@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 >     We then simplify the zero_extension into a subreg, which is OK given
 >     #2 in the semantics Jim detailed.
 > 
 > I disagree and I think this is the core of the problem.  The ZERO_EXTEND
 > forces the high bits to zero, but the paradoxical subreg says we don't
 > know/care what they are.  I don't think that's a valid "simplification".
That rather directly conflicts with the code in various parts of the
compiler.    For example this code from combine.c::nonzero_bits:

    case SUBREG:
      /* If this is a SUBREG formed for a promoted variable that has
         been zero-extended, we know that at least the high-order bits
         are zero, though others might be too.  */

      if (SUBREG_PROMOTED_VAR_P (x) && SUBREG_PROMOTED_UNSIGNED_P (x))
        nonzero = (GET_MODE_MASK (GET_MODE (x))
                   & nonzero_bits (SUBREG_REG (x), GET_MODE (x)));

      /* If the inner mode is a single word for both the host and target
         machines, we can compute this from which bits of the inner
         object might be nonzero.  */
      if (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x))) <= BITS_PER_WORD
          && (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x)))
              <= HOST_BITS_PER_WIDE_INT))
        {
          nonzero &= nonzero_bits (SUBREG_REG (x), mode);

#if defined (WORD_REGISTER_OPERATIONS) && defined (LOAD_EXTEND_OP)
          /* If this is a typical RISC machine, we only have to worry
             about the way loads are extended.  */
          if (LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) == SIGN_EXTEND
              ? (((nonzero
                   & (((unsigned HOST_WIDE_INT) 1
                       << (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x))) - 1))))
                  != 0))
              : LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) != ZERO_EXTEND)
#endif
            {
              /* On many CISC machines, accessing an object in a wider mode
                 causes the high-order bits to become undefined.  So they are
                 not known to be zero.  */
              if (GET_MODE_SIZE (GET_MODE (x))
                  > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))
                nonzero |= (GET_MODE_MASK (GET_MODE (x))
                            & ~GET_MODE_MASK (GET_MODE (SUBREG_REG (x))));
            }
        }
      break;


Or in num_sign_bit_copies:

#ifdef WORD_REGISTER_OPERATIONS
#ifdef LOAD_EXTEND_OP
      /* For paradoxical SUBREGs on machines where all register operations
         affect the entire register, just look inside.  Note that we are
         passing MODE to the recursive call, so the number of sign bit copies
         will remain relative to that mode, not the inner mode.  */

      /* This works only if loads sign extend.  Otherwise, if we get a
         reload for the inner part, it may be loaded from the stack, and
         then we lose all sign bit copies that existed before the store
         to the stack.  */

      if ((GET_MODE_SIZE (GET_MODE (x))
           > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))
          && LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) == SIGN_EXTEND)
        return num_sign_bit_copies (SUBREG_REG (x), mode);
#endif
#endif
      break;



 >     So it seems like there's three cases to consider.
 > 
 > No, I really don't think so.  I see no reason to get LOAD_EXTEND_OP
 > involved here.  I'd rather say it's identical to the register case.
No, see the code above as well as Jim's comments.

jeff