> Still OK :-)
Committed as r265304.
Regards
Robin
On 10/18/18 2:10 AM, Robin Dapp wrote:
> Hi,
>
> I added a check before calling priority in restore_pattern. In the last
> version, not checking that would lead to assertion failure in priority
> since the insn might already have been scheduled.
>
> Bootstrapped and regtested on x86_64 and ppc8,
Hi,
I added a check before calling priority in restore_pattern. In the last
version, not checking that would lead to assertion failure in priority
since the insn might already have been scheduled.
Bootstrapped and regtested on x86_64 and ppc8, regtested on s390x.
Regards
Robin
--
gcc/ChangeL
On 10/16/18 12:48 AM, Robin Dapp wrote:
>> A C++ style nit/question: instead of adding a new overload
>>
>> priority (rtx_insn *, bool)
>>
>> you can add a parameter with a default value in the existing
>> static function
>>
>> priority (rtx_insn *insn, bool force_recompute = false)
>
> Somet
> A C++ style nit/question: instead of adding a new overload
>
> priority (rtx_insn *, bool)
>
> you can add a parameter with a default value in the existing
> static function
>
> priority (rtx_insn *insn, bool force_recompute = false)
Sometimes I'm still stuck in C land with GCC :), thank
On Mon, 15 Oct 2018, Robin Dapp wrote:
> * haifa-sched.c (priority): Add force_recompute parameter.
> (apply_replacement):
> Call priority () with force_recompute = true.
> (restore_pattern): Likewise.
A C++ style nit/question: instead of adding a new overload
priority
Hi,
> See my last message. I find myself wondering if we need to reset
> INSN_PRIORITY_STATUS in update_insn_after_change and/or calling
> update_insn_after_change on INSN in additional to calling it on DESC->insn.
I tried calling update_insn_after_change even before sending my message
but it se
On 10/10/18 10:03 AM, Robin Dapp wrote:
> Hi,
>
> as my last message
> (https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00280.html) did not
> garner much attention, I'm posting it in proper patch form this time.
> The problem I'm trying to solve is that an insn's priority seems
> unchanged if the pr
Hi,
as my last message
(https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00280.html) did not
garner much attention, I'm posting it in proper patch form this time.
The problem I'm trying to solve is that an insn's priority seems
unchanged if the priority of insns that depend on it is changed (and the
