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

[Richard Sandiford <richard.sandiford@arm.com>]

[Sorry for the slow response]

Jeff Law <jlaw@ventanamicro.com> writes:
> On 11/20/23 11:26, Richard Sandiford wrote:
>> 
>> 	  scalar_int_mode outer_mode;
>> 	  if (!is_a<scalar_int_mode> (GET_MODE (x), &outer_mode)
>> 	      || GET_MODE_BITSIZE (outer_mode) > 64)
>> 	    continue;
> Wouldn't we also want to verify that the size is constant, or is it the 
> case that all the variable cases are vector (and would we want to 
> actually depend on that)?

Yeah, all the variable cases are vectors.  We don't support variable-length
scalars at the moment.  (And I hope that never changes. :))

>>> +	      /* We will handle the other operand of a binary operator
>>> +		 at the bottom of the loop by resetting Y.  */
>>> +	      if (BINARY_P (src))
>>> +		y = XEXP (src, 0);
>> 
>> What about UNARY_P, given that NOT is included in the codes above?
> We'll break that inner for(;;) then iterate into the subobject, marking 
> the relevant bits live.  FWIW, the control flow of this code continues 
> to be my biggest concern from a maintenance standpoint.  Figuring it out 
> was a major pain and I've tried to document what is and what is not 
> safe.  But it's still painful to walk through.
>
> I pondered if note_uses/note_stores would be better, but concluded we'd 
> just end up with a ton of state objects to carry around and reasoning 
> about that would be just as hard.

Feels like it would be good to handle the top-level structure explicitly,
(PARALLELs, SETs, SET_SRCs, etc.), then fall back to iteration at the
point that we can no longer do better then "all registers in this expression
are fully live".

If we do that, rtx_properties might be an alternative to explicit
iteration.  The advantage of that is that it can handle destination
and sources as the top-level expression, and records whether each
register is itself a destination or source.

Thanks,
Richard