This is the mail archive of the gcc-patches@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: [RFC] Handle memset in DSE (take 2)


Jakub Jelinek <jakub@redhat.com> writes:
> +  else if (store_mode == BLKmode)
> +    {
> +      /* The store is a memset (addr, const_val, const_size).  */
> +      gcc_assert (CONST_INT_P (store_info->rhs));
> +      store_mode = int_mode_for_mode (read_mode);
> +      if (store_mode == BLKmode)
> +	read_reg = NULL_RTX;
> +      else if (store_info->rhs == const0_rtx)
> +	read_reg = extract_low_bits (read_mode, store_mode, const0_rtx);
> +      else if (GET_MODE_BITSIZE (store_mode) > HOST_BITS_PER_WIDE_INT)
> +	read_reg = NULL_RTX;
> +      else
> +	{
> +	  unsigned HOST_WIDE_INT c
> +	    = INTVAL (store_info->rhs) & (BITS_PER_UNIT - 1);
> +	  int shift = BITS_PER_UNIT;
> +	  while (shift < HOST_BITS_PER_WIDE_INT)
> +	    {
> +	      c |= (c << shift);
> +	      shift <<= 1;
> +	    }
> +	  read_reg = GEN_INT (trunc_int_for_mode (c, store_mode));
> +	  read_reg = extract_low_bits (read_mode, store_mode, read_reg);
> +	}
> +    }

Sorry for the late reply, but I don't think this is a good representation.
I know the modeless nature of CONST_INT has been an ongoing pain, but at
least we could rely on it representing a single infinite-precision constant
integer.  Overloading (const_int x) to mean a sequence of X-valued bytes
seems very confusing IMO.  In other words:

   (set (mem:BLK ...) (const_int 0))

seems reasonable for a memory clear operation, but:

   (set (mem:BLK ...) (const_int 2))

seems a bad choice for something that sets memory to (say)
0x020202020202020202020202020202.

I think we should add a new rtx constant object instead.

Richard


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