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