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

[Jeff Law <jeffreyalaw@gmail.com>]

On 11/28/23 06:36, Joern Rennecke wrote:
> On Mon, 27 Nov 2023 at 20:18, Jeff Law <jlaw@ventanamicro.com> wrote:
>>
>>
>>
>> On 11/27/23 13:03, Richard Sandiford wrote:
>>> Joern Rennecke <joern.rennecke@embecosm.com> writes:
>>>>    On 11/20/23 11:26, Richard Sandiford wrote:
>>>>>> +      /* ?!? What is the point of this adjustment to DST_MASK?  */
>>>>>> +      if (code == PLUS || code == MINUS
>>>>>> +  || code == MULT || code == ASHIFT)
>>>>>> + dst_mask
>>>>>> +  = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0;
>>>>>
>>>>> Yeah, sympathise with the ?!? here :)
>>>> Jeff Law:
>>>>> Inherited.  Like the other bit of magic I think I'll do a test with them
>>>>> pulled out to see if I can make something undesirable trigger.
>>>>
>>>> This represents the carry effect.  Even if the destination only cares about
>>>> some high order bits, you have to consider all lower order bits of the inputs.
>>>>
>>>> For ASHIFT, you could refine this in the case of a constant shift count.
>>>
>>> Ah, right.  Think it would be worth a comment.
>> Definitely.  Wouldn't SIGN_EXTEND have a similar problem?  While we
>> don't care about all the low bits, we do care about that MSB.
> 
> Yes, if bits outside of the MODE_MASK of the input (i.e. higher bits) are
> life in the output, than we want the high bit of the SIGN_EXTEND input live.
So I had a hack in my tree to do this for a while, but it was early in 
the effort to test this across more targets.  It wasn't clear at that 
point in the effort if it was correct or just working around bugs 
elsewhere.  After we had everything working across the various targets I 
pulled it out without ill effects.  It looks like you're handling it in 
your carry_backpropagate changes.

Jeff