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
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 woul
>> 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_
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. C
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. It
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.
S
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 the selective scheduler, so I can't r
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 really say what the
>>> s
>>> 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
"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 doing here.
>
> OK, I se
> 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 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
> hash_rtx_cb ().
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
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:
> https://git
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:
> https://github.com/tyomitch/
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
16 matches
Mail list logo
