That makes me wonder if there is a latent bug though. Consider pushing
args to a pure function. Could we then try to CSE the memory reference
and get it wrong because we haven't accounted for the autoinc?
>>>
>>> Can't know for sure but one would hope something would test for
>>> s
>> That makes me wonder if there is a latent bug though. Consider pushing
>> args to a pure function. Could we then try to CSE the memory reference
>> and get it wrong because we haven't accounted for the autoinc?
>
> Can't know for sure but one would hope something would test for
> side_effects_
>>> 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 y
> 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 woul
On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote:
>
> My recollection is that auto-increment addressing modes should not
> appear in the RTL in the CSE pass.
Fair enough; but they're explicitly listed in the big switch block in
hash_rtx_cb ().
Should my added line change from "invalidate_dest (XE
Hello,
While working on a port of GCC for a non-public architecture that has
pre/post-modify memory access instructions, I discovered what looks
like a bug which can cause incorrect code generation.
My suggested fix is trivial:
https://github.com/tyomitch/gcc/commit/7d9cc102adf11065358d4694109ce3
