This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible bug in cse.c affecting pre/post-modify mem access
Jeff Law <law@redhat.com> writes:
> On 05/12/2018 10:02 AM, Richard Sandiford wrote:
>> "A. Skrobov" <tyomitch@gmail.com> writes:
>>>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>>>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>>>> is used within the selective scheduler, so I can't really say what the
>>>> selective scheduler *should* be doing here.
>>>
>>> OK, I see. Now what do you think would be the best course of action?
>>> Leave everything as it is? The selective scheduler may or may not want
>>> these memory accesses ignored.
>>
>> I don't think we can assert even for cse, since AIUI these codes can
>> still be used for stack pushes and pops.
> No. We're not supposed to have any auto-inc insns prior to the auto-inc
> pass. A stack push/pop early in the compiler would have to be
> represented by a PARALLEL.
>
> It's been this way forever. It's documented in the internals manual
> somewhere.
Maybe pops was a generalisation too far :-) but I was going off:
if (MEM_P (dest))
{
#ifdef PUSH_ROUNDING
/* Stack pushes invalidate the stack pointer. */
rtx addr = XEXP (dest, 0);
if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC
&& XEXP (addr, 0) == stack_pointer_rtx)
invalidate (stack_pointer_rtx, VOIDmode);
#endif
dest = fold_rtx (dest, insn);
}
in cse_insn. These kinds of push are generated by emit_single_push_insn
during expand, so if we asserted for RTX_AUTOINC rtxes then it would
fire for this case.
Richard