Re: [RFA] New pass for sign/zero extension elimination

[Jeff Law <jeffreyalaw@gmail.com>]

On 11/20/23 11:56, Dimitar Dimitrov wrote:
> On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
> ...
>> +/* Process uses in INSN.  Set appropriate bits in LIVENOW for any chunks of
>> +   pseudos that become live, potentially filtering using bits from LIVE_TMP.
>> +
>> +   If MODIFIED is true, then optimize sign/zero extensions to SUBREGs when
>> +   the extended bits are never read and mark pseudos which had extensions
>> +   eliminated in CHANGED_PSEUDOS.  */
>> +
>> +static void
>> +ext_dce_process_uses (rtx insn, bitmap livenow, bitmap live_tmp,
>> +		      bool modify, bitmap changed_pseudos)
>> +{
>> +  /* A nonlocal goto implicitly uses the frame pointer.  */
>> +  if (JUMP_P (insn) && find_reg_note (insn, REG_NON_LOCAL_GOTO, NULL_RTX))
>> +    {
>> +      bitmap_set_range (livenow, FRAME_POINTER_REGNUM * 4, 4);
>> +      if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
>> +	bitmap_set_range (livenow, HARD_FRAME_POINTER_REGNUM * 4, 4);
>> +    }
>> +
>> +  subrtx_var_iterator::array_type array_var;
>> +  rtx pat = PATTERN (insn);
>> +  FOR_EACH_SUBRTX_VAR (iter, array_var, pat, NONCONST)
>> +    {
>> +      /* An EXPR_LIST (from call fusage) ends in NULL_RTX.  */
>> +      rtx x = *iter;
>> +      if (x == NULL_RTX)
>> +	continue;
>> +
>> +      /* So the basic idea in this FOR_EACH_SUBRTX_VAR loop is to
>> +	 handle SETs explicitly, possibly propagating live information
>> +	 into the uses.
>> +
>> +	 We may continue the loop at various points which will cause
>> +	 iteration into the next level of RTL.  Breaking from the loop
>> +	 is never safe as it can lead us to fail to process some of the
>> +	 RTL and thus not make objects live when necessary.  */
>> +      enum rtx_code xcode = GET_CODE (x);
>> +      if (xcode == SET)
>> +	{
>> +	  const_rtx dst = SET_DEST (x);
>> +	  rtx src = SET_SRC (x);
>> +	  const_rtx y;
>> +	  unsigned HOST_WIDE_INT bit = 0;
>> +
>> +	  /* The code of the RHS of a SET.  */
>> +	  enum rtx_code code = GET_CODE (src);
>> +
>> +	  /* ?!? How much of this should mirror SET handling, potentially
>> +	     being shared?   */
>> +	  if (SUBREG_BYTE (dst).is_constant () && SUBREG_P (dst))
> 
> Shouldn't SUBREG_P be checked first like:
> 	  if (SUBREG_P (dst) && SUBREG_BYTE (dst).is_constant ())
Yes, absolutely. It'll be fixed in the next update.

This also highlighted that I never added pru-elf to the configurations 
in my tester.  I remember thinking that it needed to be added, but 
obviously that mental TODO got lost.  I've just fixed that.

jeff