* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
@ 2023-07-31 10:54 Richard Biener
2023-07-31 15:58 ` Jeff Law
0 siblings, 1 reply; 7+ messages in thread
From: Richard Biener @ 2023-07-31 10:54 UTC (permalink / raw)
To: gcc-patches; +Cc: vmakarov
On Tue, 25 Jul 2023, Richard Biener wrote:
> The following applies a micro-optimization to find_hard_regno_for_1,
> re-ordering the check so we can easily jump-thread by using an else.
> This reduces the time spent in this function by 15% for the testcase
> in the PR.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
> passes?
Ping.
> Thanks,
> Richard.
>
> PR rtl-optimization/110587
> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
> ---
> gcc/lra-assigns.cc | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
> index b8582dcafff..d2ebcfd5056 100644
> --- a/gcc/lra-assigns.cc
> +++ b/gcc/lra-assigns.cc
> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int try_only_hard_regno,
> r2 != NULL;
> r2 = r2->start_next)
> {
> - if (r2->regno >= lra_constraint_new_regno_start
> + if (live_pseudos_reg_renumber[r2->regno] < 0
> + && r2->regno >= lra_constraint_new_regno_start
> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
> - && live_pseudos_reg_renumber[r2->regno] < 0
> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
> r2->regno);
> - if (live_pseudos_reg_renumber[r2->regno] >= 0
> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
> + && rclass_intersect_p
> + [regno_allocno_class_array[r2->regno]])
> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
> }
> }
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
2023-07-31 10:54 [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1 Richard Biener
@ 2023-07-31 15:58 ` Jeff Law
2023-08-02 8:16 ` Richard Biener
0 siblings, 1 reply; 7+ messages in thread
From: Jeff Law @ 2023-07-31 15:58 UTC (permalink / raw)
To: Richard Biener, gcc-patches; +Cc: vmakarov
On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
> On Tue, 25 Jul 2023, Richard Biener wrote:
>
>> The following applies a micro-optimization to find_hard_regno_for_1,
>> re-ordering the check so we can easily jump-thread by using an else.
>> This reduces the time spent in this function by 15% for the testcase
>> in the PR.
>>
>> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
>> passes?
>
> Ping.
>
>> Thanks,
>> Richard.
>>
>> PR rtl-optimization/110587
>> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
>> ---
>> gcc/lra-assigns.cc | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
>> index b8582dcafff..d2ebcfd5056 100644
>> --- a/gcc/lra-assigns.cc
>> +++ b/gcc/lra-assigns.cc
>> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int try_only_hard_regno,
>> r2 != NULL;
>> r2 = r2->start_next)
>> {
>> - if (r2->regno >= lra_constraint_new_regno_start
>> + if (live_pseudos_reg_renumber[r2->regno] < 0
>> + && r2->regno >= lra_constraint_new_regno_start
>> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
>> - && live_pseudos_reg_renumber[r2->regno] < 0
>> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
>> r2->regno);
>> - if (live_pseudos_reg_renumber[r2->regno] >= 0
>> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
>> + && rclass_intersect_p
>> + [regno_allocno_class_array[r2->regno]])
>> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
My biggest concern here would be r2->regno < 0 in the new code which
could cause an OOB array reference in the first condition of the test.
Isn't that the point if the original ordering? Test that r2->regno is
reasonable before using it as an array index?
jeff
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
2023-07-31 15:58 ` Jeff Law
@ 2023-08-02 8:16 ` Richard Biener
2023-08-07 13:18 ` Richard Biener
0 siblings, 1 reply; 7+ messages in thread
From: Richard Biener @ 2023-08-02 8:16 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches, vmakarov
On Mon, 31 Jul 2023, Jeff Law wrote:
>
>
> On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
> > On Tue, 25 Jul 2023, Richard Biener wrote:
> >
> >> The following applies a micro-optimization to find_hard_regno_for_1,
> >> re-ordering the check so we can easily jump-thread by using an else.
> >> This reduces the time spent in this function by 15% for the testcase
> >> in the PR.
> >>
> >> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
> >> passes?
> >
> > Ping.
> >
> >> Thanks,
> >> Richard.
> >>
> >> PR rtl-optimization/110587
> >> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
> >> ---
> >> gcc/lra-assigns.cc | 9 +++++----
> >> 1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
> >> index b8582dcafff..d2ebcfd5056 100644
> >> --- a/gcc/lra-assigns.cc
> >> +++ b/gcc/lra-assigns.cc
> >> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int
> >> @@ try_only_hard_regno,
> >> r2 != NULL;
> >> r2 = r2->start_next)
> >> {
> >> - if (r2->regno >= lra_constraint_new_regno_start
> >> + if (live_pseudos_reg_renumber[r2->regno] < 0
> >> + && r2->regno >= lra_constraint_new_regno_start
> >> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
> >> - && live_pseudos_reg_renumber[r2->regno] < 0
> >> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> >> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
> >> r2->regno);
> >> - if (live_pseudos_reg_renumber[r2->regno] >= 0
> >> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> >> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
> >> + && rclass_intersect_p
> >> + [regno_allocno_class_array[r2->regno]])
> >> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
> My biggest concern here would be r2->regno < 0 in the new code which could
> cause an OOB array reference in the first condition of the test.
>
> Isn't that the point if the original ordering? Test that r2->regno is
> reasonable before using it as an array index?
Note the original code is
if (r2->regno >= lra_constraint_new_regno_start
...
if (live_pseudos_reg_renumber[r2->regno] >= 0
...
so we are going to access live_pseudos_reg_renumber[r2->regno]
independent on the r2->regno >= lra_constraint_new_regno_start check,
so I don't think that's the point of the original ordering. Note
I preserved the ordering with respect to other array accesses,
the speedup seen is because we now have the
if (live_pseudos_reg_renumber[r2->regno] < 0
...
else if (live_pseudos_reg_renumber[r2->regno] >= 0
...
structure directly exposed which helps the compiler.
I think the check on r2->regno is to decide whether to alter
conflict_reload_and_inheritance_pseudos or
live_range_hard_reg_pseudos (so it's also somewhat natural to check
that first).
Thanks,
Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
2023-08-02 8:16 ` Richard Biener
@ 2023-08-07 13:18 ` Richard Biener
2023-08-08 16:49 ` Vladimir Makarov
0 siblings, 1 reply; 7+ messages in thread
From: Richard Biener @ 2023-08-07 13:18 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches, vmakarov
On Wed, 2 Aug 2023, Richard Biener wrote:
> On Mon, 31 Jul 2023, Jeff Law wrote:
>
> >
> >
> > On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
> > > On Tue, 25 Jul 2023, Richard Biener wrote:
> > >
> > >> The following applies a micro-optimization to find_hard_regno_for_1,
> > >> re-ordering the check so we can easily jump-thread by using an else.
> > >> This reduces the time spent in this function by 15% for the testcase
> > >> in the PR.
> > >>
> > >> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
> > >> passes?
> > >
> > > Ping.
> > >
> > >> Thanks,
> > >> Richard.
> > >>
> > >> PR rtl-optimization/110587
> > >> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
> > >> ---
> > >> gcc/lra-assigns.cc | 9 +++++----
> > >> 1 file changed, 5 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
> > >> index b8582dcafff..d2ebcfd5056 100644
> > >> --- a/gcc/lra-assigns.cc
> > >> +++ b/gcc/lra-assigns.cc
> > >> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int
> > >> @@ try_only_hard_regno,
> > >> r2 != NULL;
> > >> r2 = r2->start_next)
> > >> {
> > >> - if (r2->regno >= lra_constraint_new_regno_start
> > >> + if (live_pseudos_reg_renumber[r2->regno] < 0
> > >> + && r2->regno >= lra_constraint_new_regno_start
> > >> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
> > >> - && live_pseudos_reg_renumber[r2->regno] < 0
> > >> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> > >> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
> > >> r2->regno);
> > >> - if (live_pseudos_reg_renumber[r2->regno] >= 0
> > >> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> > >> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
> > >> + && rclass_intersect_p
> > >> + [regno_allocno_class_array[r2->regno]])
> > >> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
> > My biggest concern here would be r2->regno < 0 in the new code which could
> > cause an OOB array reference in the first condition of the test.
> >
> > Isn't that the point if the original ordering? Test that r2->regno is
> > reasonable before using it as an array index?
>
> Note the original code is
>
> if (r2->regno >= lra_constraint_new_regno_start
> ...
> if (live_pseudos_reg_renumber[r2->regno] >= 0
> ...
>
> so we are going to access live_pseudos_reg_renumber[r2->regno]
> independent on the r2->regno >= lra_constraint_new_regno_start check,
> so I don't think that's the point of the original ordering. Note
> I preserved the ordering with respect to other array accesses,
> the speedup seen is because we now have the
>
>
> if (live_pseudos_reg_renumber[r2->regno] < 0
> ...
> else if (live_pseudos_reg_renumber[r2->regno] >= 0
> ...
>
> structure directly exposed which helps the compiler.
>
> I think the check on r2->regno is to decide whether to alter
> conflict_reload_and_inheritance_pseudos or
> live_range_hard_reg_pseudos (so it's also somewhat natural to check
> that first).
So - OK?
Thanks,
Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
2023-08-07 13:18 ` Richard Biener
@ 2023-08-08 16:49 ` Vladimir Makarov
2023-08-08 16:50 ` Jeff Law
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Makarov @ 2023-08-08 16:49 UTC (permalink / raw)
To: Richard Biener, Jeff Law; +Cc: gcc-patches
On 8/7/23 09:18, Richard Biener wrote:
> On Wed, 2 Aug 2023, Richard Biener wrote:
>
>> On Mon, 31 Jul 2023, Jeff Law wrote:
>>
>>>
>>> On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
>>>> On Tue, 25 Jul 2023, Richard Biener wrote:
>>>>
>>>>> The following applies a micro-optimization to find_hard_regno_for_1,
>>>>> re-ordering the check so we can easily jump-thread by using an else.
>>>>> This reduces the time spent in this function by 15% for the testcase
>>>>> in the PR.
>>>>>
>>>>> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
>>>>> passes?
>>>> Ping.
>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>> PR rtl-optimization/110587
>>>>> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
>>>>> ---
>>>>> gcc/lra-assigns.cc | 9 +++++----
>>>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
>>>>> index b8582dcafff..d2ebcfd5056 100644
>>>>> --- a/gcc/lra-assigns.cc
>>>>> +++ b/gcc/lra-assigns.cc
>>>>> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int
>>>>> @@ try_only_hard_regno,
>>>>> r2 != NULL;
>>>>> r2 = r2->start_next)
>>>>> {
>>>>> - if (r2->regno >= lra_constraint_new_regno_start
>>>>> + if (live_pseudos_reg_renumber[r2->regno] < 0
>>>>> + && r2->regno >= lra_constraint_new_regno_start
>>>>> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
>>>>> - && live_pseudos_reg_renumber[r2->regno] < 0
>>>>> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>>>>> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
>>>>> r2->regno);
>>>>> - if (live_pseudos_reg_renumber[r2->regno] >= 0
>>>>> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>>>>> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
>>>>> + && rclass_intersect_p
>>>>> + [regno_allocno_class_array[r2->regno]])
>>>>> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
>>> My biggest concern here would be r2->regno < 0 in the new code which could
>>> cause an OOB array reference in the first condition of the test.
>>>
>>> Isn't that the point if the original ordering? Test that r2->regno is
>>> reasonable before using it as an array index?
>> Note the original code is
>>
>> if (r2->regno >= lra_constraint_new_regno_start
>> ...
>> if (live_pseudos_reg_renumber[r2->regno] >= 0
>> ...
>>
>> so we are going to access live_pseudos_reg_renumber[r2->regno]
>> independent on the r2->regno >= lra_constraint_new_regno_start check,
>> so I don't think that's the point of the original ordering. Note
>> I preserved the ordering with respect to other array accesses,
>> the speedup seen is because we now have the
>>
>>
>> if (live_pseudos_reg_renumber[r2->regno] < 0
>> ...
>> else if (live_pseudos_reg_renumber[r2->regno] >= 0
>> ...
>>
>> structure directly exposed which helps the compiler.
>>
>> I think the check on r2->regno is to decide whether to alter
>> conflict_reload_and_inheritance_pseudos or
>> live_range_hard_reg_pseudos (so it's also somewhat natural to check
>> that first).
> So - OK?
>
Richard, sorry, I overlooked this thread.
Yes, it is OK to commit. In general Jeff has a reasonable concern but
in this case r2->regno is always >= 0 and I can not imagine reasons that
we will change algorithm in the future in such way when it is not true.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
2023-08-08 16:49 ` Vladimir Makarov
@ 2023-08-08 16:50 ` Jeff Law
0 siblings, 0 replies; 7+ messages in thread
From: Jeff Law @ 2023-08-08 16:50 UTC (permalink / raw)
To: Vladimir Makarov, Richard Biener; +Cc: gcc-patches
On 8/8/23 10:49, Vladimir Makarov wrote:
>
> On 8/7/23 09:18, Richard Biener wrote:
>> On Wed, 2 Aug 2023, Richard Biener wrote:
>>
>>> On Mon, 31 Jul 2023, Jeff Law wrote:
>>>
>>>>
>>>> On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
>>>>> On Tue, 25 Jul 2023, Richard Biener wrote:
>>>>>
>>>>>> The following applies a micro-optimization to find_hard_regno_for_1,
>>>>>> re-ordering the check so we can easily jump-thread by using an else.
>>>>>> This reduces the time spent in this function by 15% for the testcase
>>>>>> in the PR.
>>>>>>
>>>>>> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
>>>>>> passes?
>>>>> Ping.
>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>>>
>>>>>> PR rtl-optimization/110587
>>>>>> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
>>>>>> ---
>>>>>> gcc/lra-assigns.cc | 9 +++++----
>>>>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
>>>>>> index b8582dcafff..d2ebcfd5056 100644
>>>>>> --- a/gcc/lra-assigns.cc
>>>>>> +++ b/gcc/lra-assigns.cc
>>>>>> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost,
>>>>>> int
>>>>>> @@ try_only_hard_regno,
>>>>>> r2 != NULL;
>>>>>> r2 = r2->start_next)
>>>>>> {
>>>>>> - if (r2->regno >= lra_constraint_new_regno_start
>>>>>> + if (live_pseudos_reg_renumber[r2->regno] < 0
>>>>>> + && r2->regno >= lra_constraint_new_regno_start
>>>>>> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
>>>>>> - && live_pseudos_reg_renumber[r2->regno] < 0
>>>>>> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>>>>>> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
>>>>>> r2->regno);
>>>>>> - if (live_pseudos_reg_renumber[r2->regno] >= 0
>>>>>> - &&
>>>>>> rclass_intersect_p[regno_allocno_class_array[r2->regno]])
>>>>>> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
>>>>>> + && rclass_intersect_p
>>>>>> + [regno_allocno_class_array[r2->regno]])
>>>>>> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
>>>> My biggest concern here would be r2->regno < 0 in the new code
>>>> which could
>>>> cause an OOB array reference in the first condition of the test.
>>>>
>>>> Isn't that the point if the original ordering? Test that r2->regno is
>>>> reasonable before using it as an array index?
>>> Note the original code is
>>>
>>> if (r2->regno >= lra_constraint_new_regno_start
>>> ...
>>> if (live_pseudos_reg_renumber[r2->regno] >= 0
>>> ...
>>>
>>> so we are going to access live_pseudos_reg_renumber[r2->regno]
>>> independent on the r2->regno >= lra_constraint_new_regno_start check,
>>> so I don't think that's the point of the original ordering. Note
>>> I preserved the ordering with respect to other array accesses,
>>> the speedup seen is because we now have the
>>>
>>>
>>> if (live_pseudos_reg_renumber[r2->regno] < 0
>>> ...
>>> else if (live_pseudos_reg_renumber[r2->regno] >= 0
>>> ...
>>>
>>> structure directly exposed which helps the compiler.
>>>
>>> I think the check on r2->regno is to decide whether to alter
>>> conflict_reload_and_inheritance_pseudos or
>>> live_range_hard_reg_pseudos (so it's also somewhat natural to check
>>> that first).
>> So - OK?
>>
> Richard, sorry, I overlooked this thread.
>
> Yes, it is OK to commit. In general Jeff has a reasonable concern but
> in this case r2->regno is always >= 0 and I can not imagine reasons that
> we will change algorithm in the future in such way when it is not true.
Thanks for confirming it's a non-issue. No objection from me.
jeff
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
@ 2023-07-25 13:40 Richard Biener
0 siblings, 0 replies; 7+ messages in thread
From: Richard Biener @ 2023-07-25 13:40 UTC (permalink / raw)
To: gcc-patches
The following applies a micro-optimization to find_hard_regno_for_1,
re-ordering the check so we can easily jump-thread by using an else.
This reduces the time spent in this function by 15% for the testcase
in the PR.
Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
passes?
Thanks,
Richard.
PR rtl-optimization/110587
* lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
---
gcc/lra-assigns.cc | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
index b8582dcafff..d2ebcfd5056 100644
--- a/gcc/lra-assigns.cc
+++ b/gcc/lra-assigns.cc
@@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int try_only_hard_regno,
r2 != NULL;
r2 = r2->start_next)
{
- if (r2->regno >= lra_constraint_new_regno_start
+ if (live_pseudos_reg_renumber[r2->regno] < 0
+ && r2->regno >= lra_constraint_new_regno_start
&& lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
- && live_pseudos_reg_renumber[r2->regno] < 0
&& rclass_intersect_p[regno_allocno_class_array[r2->regno]])
sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
r2->regno);
- if (live_pseudos_reg_renumber[r2->regno] >= 0
- && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
+ else if (live_pseudos_reg_renumber[r2->regno] >= 0
+ && rclass_intersect_p
+ [regno_allocno_class_array[r2->regno]])
sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
}
}
--
2.35.3
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-08-08 16:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-31 10:54 [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1 Richard Biener
2023-07-31 15:58 ` Jeff Law
2023-08-02 8:16 ` Richard Biener
2023-08-07 13:18 ` Richard Biener
2023-08-08 16:49 ` Vladimir Makarov
2023-08-08 16:50 ` Jeff Law
-- strict thread matches above, loose matches on Subject: below --
2023-07-25 13:40 Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).