Re: [RFA] Avoid unnecessary load-immediate in coremark

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/30/22 04:47, Richard Sandiford wrote:
> Jeff Law <jlaw@ventanamicro.com> writes:
>> This is another minor improvement to coremark.   I suspect this only
>> improves code size as the load-immediate was likely issuing with the ret
>> statement on multi-issue machines.
>>
>>
>> Basically we're failing to utilize conditional equivalences during the
>> post-reload CSE pass.  So if a particular block is only reached when a
>> certain condition holds (say for example a4 == 0) and the block has an
>> assignment like a4 = 0, we would fail to eliminate the unnecessary
>> assignment.
> I wasn't sure (and was too lazy to try, sorry), but: is the reason
> that we fail to catch this earlier because the two uses of r4 are
> entirely separate (i.e. not from the same pseudo)?

Right.  Different pseudos used in the comparison vs the destination of 
the assignment.  If they used the same pseudo, then I would have 
expected cse or gcse to pick it up.



>
>> +	  /* Iterate over each incoming edge and see if they
>> +	     all have the same implicit set.  */
>> +	  FOR_EACH_EDGE (e, ei, bb->preds)
>> +	    {
>> +	      /* If the predecessor does not end in a conditional
>> +		 jump, then it does not have an implicit set.  */
>> +	      if (e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
>> +		  && !block_ends_with_condjump_p (e->src))
>> +		{
>> +		  found = false;
>> +		  break;
>> +		}
>> +
>> +	      /* We know the predecessor ends with a conditional
>> +		 jump.  Now dig into the actal form of the jump
>> +		 to potentially extract an implicit set.  */
> Very minor, but it looked odd to fall through for the entry block.
> How about:
>
> 	      if (e->src == ENTRY_BLOCK_PTR_FOR_FN (cfun)
> 		  || !block_ends_with_condjump_p (e->src))
>
> ?

Looks like a mistake to me.  we don't want to process anything for a 
successor of the entry block.  I'll adjust and retest.


Thanks,

Jeff