Re: Possible bug in cse.c affecting pre/post-modify mem access

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 >>>

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/15/2018 12:58 PM, A. Skrobov wrote: >>> 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

>> 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 >

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/14/2018 10:55 PM, Jeff Law wrote: > That does sound vaguely familiar. Did we put autoinc notes on the stack > pushes? Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps. > That makes me wonder if there is a latent bug though. Consider pushing > args to a pure function.

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 01:35 PM, Bernd Schmidt wrote: > On 05/12/2018 07:01 PM, Jeff Law wrote: > >> 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.

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 07:01 PM, Jeff Law wrote: > 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.

Re: Possible bug in cse.c affecting pre/post-modify mem access

Jeff Law writes: > On 05/12/2018 10:02 AM, Richard Sandiford wrote: >> "A. Skrobov" 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 10:02 AM, Richard Sandiford wrote: > "A. Skrobov" 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

>>> 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

"A. Skrobov" 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

> 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/10/2018 11:45 PM, A. Skrobov wrote: > 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

Re: Possible bug in cse.c affecting pre/post-modify mem access

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

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/10/2018 01:44 PM, A. Skrobov wrote: > 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: >

Re: Possible bug in cse.c affecting pre/post-modify mem access

Hi, "A. Skrobov" writes: > 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: >

Possible bug in cse.c affecting pre/post-modify mem access

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: