On 6/3/23 12:38, Georg-Johann Lay wrote:

>>>         }
>>>
>>>       note_stores (insn, move2add_note_store, insn);
> 
> The point is that in the continue block, the effect of the insn is
> recorded even if !success, it's just the computed effect of the code.
> 
> Moreover, "next" is REG = REG + CONST_INT, so there are no REG_INC
> notes, no?
> 
> Also I don't have any testcases that break other than the one
> that has a clobber of a GPR along with the pointer addition.
> 
> I tried some "smart" solutions before, but all failed for some
> reason, so I resorted to something that fixes the bug, and
> *only* fixes the bug, and which has clearly no other side
> effects than fixing the bug (I have to do all remote on compile
> farm).  If a more elaborate fix is needed that also catches other
> PRs, then I would hand this over to a postreload maintainer please.
> 
>> Of particular importance for your case would be the note_stores call. 
>> But I could well see other targets needing the search for REG_INC 
>> notes as well as stack pushes.
>>
>> If I'm right, then wouldn't it be better to factor that blob of code 
>> above into its own function, then use it before the "continue" rather 
>> than implementing a custom can for CLOBBERS?
> 
> I cannot answer that.  Maybe the authors of the code have some ideas.
Here's what I was thinking.  I don't have the bits here to build newlib 
or a simulator, so if you could give it a test it'd be appreciated.

I suspect the note_stores call is the important one in here since as you 
note we're dealing with simple arithmetic and I wouldn't expect to have 
REG_INC notes or SP autoincs in that scenario.

Jeff