* patch to fix PR82353
@ 2017-10-16 20:39 Vladimir Makarov
2017-12-13 12:35 ` Tom de Vries
0 siblings, 1 reply; 11+ messages in thread
From: Vladimir Makarov @ 2017-10-16 20:39 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
This is another version of the patch to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
The patch was successfully bootstrapped on x86-64 with Go and Ada.
Committed as rev. 253796.
[-- Attachment #2: pr82353-2.patch --]
[-- Type: text/x-patch, Size: 2766 bytes --]
Index: ChangeLog
===================================================================
--- ChangeLog (revision 253795)
+++ ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2017-10-16 Vladimir Makarov <vmakarov@redhat.com>
+
+ PR sanitizer/82353
+ * lra.c (collect_non_operand_hard_regs): Don't ignore operator
+ locations.
+ * lra-lives.c (bb_killed_pseudos, bb_gen_pseudos): Move up.
+ (make_hard_regno_born, make_hard_regno_dead): Update
+ bb_killed_pseudos and bb_gen_pseudos for fixed regs.
+
2017-10-16 Jeff Law <law@redhat.com>
* tree-ssa-dse.c (live_bytes_read): Fix thinko.
Index: lra.c
===================================================================
--- lra.c (revision 253685)
+++ lra.c (working copy)
@@ -820,7 +820,8 @@ collect_non_operand_hard_regs (rtx *x, l
const char *fmt = GET_RTX_FORMAT (code);
for (i = 0; i < data->insn_static_data->n_operands; i++)
- if (x == data->operand_loc[i])
+ if (! data->insn_static_data->operand[i].is_operator
+ && x == data->operand_loc[i])
/* It is an operand loc. Stop here. */
return list;
for (i = 0; i < data->insn_static_data->n_dups; i++)
Index: lra-lives.c
===================================================================
--- lra-lives.c (revision 253685)
+++ lra-lives.c (working copy)
@@ -220,6 +220,9 @@ lra_intersected_live_ranges_p (lra_live_
return false;
}
+/* The corresponding bitmaps of BB currently being processed. */
+static bitmap bb_killed_pseudos, bb_gen_pseudos;
+
/* The function processing birth of hard register REGNO. It updates
living hard regs, START_LIVING, and conflict hard regs for living
pseudos. Conflict hard regs for the pic pseudo is not updated if
@@ -243,6 +246,8 @@ make_hard_regno_born (int regno, bool ch
|| i != REGNO (pic_offset_table_rtx))
#endif
SET_HARD_REG_BIT (lra_reg_info[i].conflict_hard_regs, regno);
+ if (fixed_regs[regno])
+ bitmap_set_bit (bb_gen_pseudos, regno);
}
/* Process the death of hard register REGNO. This updates
@@ -255,6 +260,11 @@ make_hard_regno_dead (int regno)
return;
sparseset_set_bit (start_dying, regno);
CLEAR_HARD_REG_BIT (hard_regs_live, regno);
+ if (fixed_regs[regno])
+ {
+ bitmap_clear_bit (bb_gen_pseudos, regno);
+ bitmap_set_bit (bb_killed_pseudos, regno);
+ }
}
/* Mark pseudo REGNO as living at program point POINT, update conflicting
@@ -299,9 +309,6 @@ mark_pseudo_dead (int regno, int point)
}
}
-/* The corresponding bitmaps of BB currently being processed. */
-static bitmap bb_killed_pseudos, bb_gen_pseudos;
-
/* Mark register REGNO (pseudo or hard register) in MODE as live at
program point POINT. Update BB_GEN_PSEUDOS.
Return TRUE if the liveness tracking sets were modified, or FALSE
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch to fix PR82353
2017-10-16 20:39 patch to fix PR82353 Vladimir Makarov
@ 2017-12-13 12:35 ` Tom de Vries
2017-12-14 17:01 ` Vladimir Makarov
0 siblings, 1 reply; 11+ messages in thread
From: Tom de Vries @ 2017-12-13 12:35 UTC (permalink / raw)
To: Vladimir Makarov, gcc-patches
On 10/16/2017 10:38 PM, Vladimir Makarov wrote:
> This is another version of the patch to fix
>
> Â Â https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
>
> The patch was successfully bootstrapped on x86-64 with Go and Ada.
>
> Committed as rev. 253796.
Hi Vladimir,
AFAIU this bit of the patch makes sure that the flags register show up
in the bb_livein of the bb in which it's used (and not defined before
the use), but not in the bb_liveout of the predecessors of that bb.
I wonder if that's a compile-speed optimization, or an oversight.
[ I ran into a similar problem for target gcn here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327 ) with the
spill_class hook. I've posted a tentative fix in that PR, which
piggybacks on this fix, but needed a few extra bits to make sure that
inter-bb propagation was done:
- a bit at the end of process_bb_lives to detect the liveness change and
then set live_change_p which make sure the propagation is run.
- a bit in lra_create_live_ranges_1 to unmask the registers we want to
propagate in all_hard_regs_bitmap.
]
Thanks,
- Tom
> Index: lra-lives.c
> ===================================================================
> --- lra-lives.c (revision 253685)
> +++ lra-lives.c (working copy)
> @@ -220,6 +220,9 @@ lra_intersected_live_ranges_p (lra_live_
> return false;
> }
>
> +/* The corresponding bitmaps of BB currently being processed. */
> +static bitmap bb_killed_pseudos, bb_gen_pseudos;
> +
> /* The function processing birth of hard register REGNO. It updates
> living hard regs, START_LIVING, and conflict hard regs for living
> pseudos. Conflict hard regs for the pic pseudo is not updated if
> @@ -243,6 +246,8 @@ make_hard_regno_born (int regno, bool ch
> || i != REGNO (pic_offset_table_rtx))
> #endif
> SET_HARD_REG_BIT (lra_reg_info[i].conflict_hard_regs, regno);
> + if (fixed_regs[regno])
> + bitmap_set_bit (bb_gen_pseudos, regno);
> }
>
> /* Process the death of hard register REGNO. This updates
> @@ -255,6 +260,11 @@ make_hard_regno_dead (int regno)
> return;
> sparseset_set_bit (start_dying, regno);
> CLEAR_HARD_REG_BIT (hard_regs_live, regno);
> + if (fixed_regs[regno])
> + {
> + bitmap_clear_bit (bb_gen_pseudos, regno);
> + bitmap_set_bit (bb_killed_pseudos, regno);
> + }
> }
>
> /* Mark pseudo REGNO as living at program point POINT, update conflicting
> @@ -299,9 +309,6 @@ mark_pseudo_dead (int regno, int point)
> }
> }
>
> -/* The corresponding bitmaps of BB currently being processed. */
> -static bitmap bb_killed_pseudos, bb_gen_pseudos;
> -
> /* Mark register REGNO (pseudo or hard register) in MODE as live at
> program point POINT. Update BB_GEN_PSEUDOS.
> Return TRUE if the liveness tracking sets were modified, or FALSE
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch to fix PR82353
2017-12-13 12:35 ` Tom de Vries
@ 2017-12-14 17:01 ` Vladimir Makarov
2017-12-15 11:26 ` [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs Tom de Vries
0 siblings, 1 reply; 11+ messages in thread
From: Vladimir Makarov @ 2017-12-14 17:01 UTC (permalink / raw)
To: Tom de Vries, gcc-patches
On 12/13/2017 07:34 AM, Tom de Vries wrote:
> On 10/16/2017 10:38 PM, Vladimir Makarov wrote:
>> This is another version of the patch to fix
>>
>> Â Â Â https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
>>
>> The patch was successfully bootstrapped on x86-64 with Go and Ada.
>>
>> Committed as rev. 253796.
>
> Hi Vladimir,
>
> AFAIU this bit of the patch makes sure that the flags register show up
> in the bb_livein of the bb in which it's used (and not defined before
> the use), but not in the bb_liveout of the predecessors of that bb.
>
> I wonder if that's a compile-speed optimization, or an oversight.
>
Hi, Tom. It was just a minimal fix. I prefer minimal fixes for LRA
because even for me it is hard to predict in many cases how the patch
will affect all the targets. Therefore many LRA patches have a few
iterations before to be final.
I remember that I had some serious problems in the past when I tried to
implement fixed hard reg liveness propagation in LRA. It was long ago
so we could try it again. If you send patch you mentioned to gcc
mailing list, I'll review and approve it. But we need to be ready to
revert it if some problems occur again.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2017-12-14 17:01 ` Vladimir Makarov
@ 2017-12-15 11:26 ` Tom de Vries
2017-12-18 16:57 ` Vladimir Makarov
0 siblings, 1 reply; 11+ messages in thread
From: Tom de Vries @ 2017-12-15 11:26 UTC (permalink / raw)
To: Vladimir Makarov, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 5216 bytes --]
[ was: Re: patch to fix PR82353 ]
On 12/14/2017 06:01 PM, Vladimir Makarov wrote:
>
>
> On 12/13/2017 07:34 AM, Tom de Vries wrote:
>> On 10/16/2017 10:38 PM, Vladimir Makarov wrote:
>>> This is another version of the patch to fix
>>>
>>> Â Â Â https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
>>>
>>> The patch was successfully bootstrapped on x86-64 with Go and Ada.
>>>
>>> Committed as rev. 253796.
>>
>> Hi Vladimir,
>>
>> AFAIU this bit of the patch makes sure that the flags register show up
>> in the bb_livein of the bb in which it's used (and not defined before
>> the use), but not in the bb_liveout of the predecessors of that bb.
>>
>> I wonder if that's a compile-speed optimization, or an oversight.
>>
> Hi, Tom. It was just a minimal fix. I prefer minimal fixes for LRA
> because even for me it is hard to predict in many cases how the patch
> will affect all the targets. Therefore many LRA patches have a few
> iterations before to be final.
>
I see, thanks for the explanation.
> I remember that I had some serious problems in the past when I tried to
> implement fixed hard reg liveness propagation in LRA. It was long ago
> so we could try it again. If you send patch you mentioned to gcc
> mailing list, I'll review and approve it.
Here it is. It applies cleanly to trunk (and to gcc-7-branch if you
first backport r253796, the fix for PR82353).
I have not tested this on trunk sofar, only on the internal branch for
gcn based on gcc 7.1 with the gcc testsuite, where it fixes a wrong-code
bug in gcc.dg/vect/no-scevccp-outer-10.c and causes no regressions.
--------------------------------------------------------------------------
The problem on a minimal version of the test-case looks as follows:
I.
At ira, we have a def and use of 'reg:BI 605', the def in bb2 and the
use in bb3:
...
(note 44 32 33 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
...
(insn 269 54 64 2 (set (reg:BI 605)
(le:BI (reg/v:SI 491 [ n ])
(const_int 0 [0]))) 23 {cstoresi4}
(nil))
....
(code_label 250 228 56 3 7 (nil) [1 uses])
(note 56 250 58 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
...
(jump_insn 62 60 63 3 (set (pc)
(if_then_else (ne:BI (reg:BI 605)
(const_int 0 [0]))
(label_ref 242)
(pc))) "no-scevccp-outer-10.c":19 21 {cjump}
(int_list:REG_BR_PROB 1500 (nil))
-> 242)
(note 63 62 66 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
...
And in lra, we decide to spill it into a hard register:
...
Spill r605 into hr95
...
Resulting in this code:
...
(insn 385 386 64 2 (set (reg:BI 95 s95)
(reg:BI 18 s18 [605])) 3 {*movbi}
(nil))
...
(insn 404 60 405 3 (set (reg:BI 18 s18 [605])
(reg:BI 95 s95)) "no-scevccp-outer-10.c":19 3 {*movbi}
(nil))
...
II.
However, a bit later in lra we decide to assign r94,r95 to DImode pseudo
833:
...
Assign 94 to reload r833 (freq=60)
...
Resulting in this code:
...
(insn 629 378 390 2 (set (reg:DI 94 s94 [833])
(plus:DI (reg/f:DI 16 s16)
(const_int -8 [0xfffffffffffffff8]))) 35 {addptrdi3}
(nil))
...
This clobbers the def of s95 in insn 385.
III.
Consequently, the insn is removed in the dce in the jump pass:
...
DCE: Deleting insn 385
deleting insn with uid = 385.
...
--------------------------------------------------------------------------
Analysis:
The decision to assign r94,r95 to DImode pseudo 833 happens because r95
is not marked in the conflict_hard_regs of lra_reg_info[833] during
liveness analysis.
There's code in make_hard_regno_born to set the reg in the
conflict_hard_regs of live pseudos, but at the point that r95 becomes
live, the r833 pseudo is not live.
Then there's code in mark_pseudo_live to set the hard_regs_live in the
conflict_hard_regs of the pseudo, but at the point that r833 becomes
live, r95 is not set in hard_regs_live, due to the fact that it's not
set in df_get_live_out (bb2).
In other words, the root cause is that hard reg liveness propagation is
not done.
--------------------------------------------------------------------------
Proposed Solution:
The patch addresses the problem, by:
- marking the hard regs that have been used in lra_spill in
hard_regs_spilled_into
- using hard_regs_spilled_into in lra_create_live_ranges to
make sure those registers are marked in the conflict_hard_regs
of pseudos that overlap with the spill register usage
[ I've also tried an approach where I didn't use hard_regs_spilled_into,
but tried to propagate all hard regs. I figured out that I needed to
mask out eliminable_regset. Also I needed to masked out
lra_no_alloc_regs, but that could be due to gcn-specific problems
(pointers take 2 hard regs), I'm not yet sure. Anyway, in the submitted
patch I tried to avoid these problems and went for the more minimal
approach. ]
In order to get the patch accepted for trunk, I think we need:
- bootstrap and reg-test on x86_64
- build and reg-test on mips (the only primary platform that has the
spill_class hook enabled)
Any comments?
> But we need to be ready to
> revert it if some problems occur again.
>
Understood.
Thanks,
- Tom
[-- Attachment #2: 0001-Fix-liveness-analysis-in-lra-for-spilled-into-hard-regs.patch --]
[-- Type: text/x-patch, Size: 4428 bytes --]
Fix liveness analysis in lra for spilled-into hard regs
2017-12-12 Tom de Vries <tom@codesourcery.com>
PR rtl-optimization/83327
* lra-int.h (hard_regs_spilled_into): Declare.
* lra.c (hard_regs_spilled_into): Define.
(init_reg_info): Init hard_regs_spilled_into.
* lra-spills.c (assign_spill_hard_regs): Update hard_regs_spilled_into.
* lra-lives.c (make_hard_regno_born, make_hard_regno_dead)
(process_bb_lives): Handle hard_regs_spilled_into.
(lra_create_live_ranges_1): Before doing liveness propagation, clear
regs in all_hard_regs_bitmap if set in hard_regs_spilled_into.
---
gcc/lra-int.h | 2 ++
gcc/lra-lives.c | 28 ++++++++++++++++++++++++++--
gcc/lra-spills.c | 2 ++
gcc/lra.c | 3 +++
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/gcc/lra-int.h b/gcc/lra-int.h
index 5a519b0..064961a 100644
--- a/gcc/lra-int.h
+++ b/gcc/lra-int.h
@@ -122,6 +122,8 @@ struct lra_reg
/* References to the common info about each register. */
extern struct lra_reg *lra_reg_info;
+extern HARD_REG_SET hard_regs_spilled_into;
+
/* Static info about each insn operand (common for all insns with the
same ICODE). Warning: if the structure definition is changed, the
initializer for debug_operand_data in lra.c should be changed
diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index 03dfec2..85da626 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -245,7 +245,7 @@ make_hard_regno_born (int regno, bool check_pic_pseudo_p ATTRIBUTE_UNUSED)
|| i != REGNO (pic_offset_table_rtx))
#endif
SET_HARD_REG_BIT (lra_reg_info[i].conflict_hard_regs, regno);
- if (fixed_regs[regno])
+ if (fixed_regs[regno] || TEST_HARD_REG_BIT (hard_regs_spilled_into, regno))
bitmap_set_bit (bb_gen_pseudos, regno);
}
@@ -259,7 +259,7 @@ make_hard_regno_dead (int regno)
return;
sparseset_set_bit (start_dying, regno);
CLEAR_HARD_REG_BIT (hard_regs_live, regno);
- if (fixed_regs[regno])
+ if (fixed_regs[regno] || TEST_HARD_REG_BIT (hard_regs_spilled_into, regno))
{
bitmap_clear_bit (bb_gen_pseudos, regno);
bitmap_set_bit (bb_killed_pseudos, regno);
@@ -1051,6 +1051,25 @@ process_bb_lives (basic_block bb, int &curr_point, bool dead_insn_p)
check_pseudos_live_through_calls (j, last_call_used_reg_set);
}
+ for (i = 0; i < FIRST_PSEUDO_REGISTER; ++i)
+ {
+ if (!TEST_HARD_REG_BIT (hard_regs_live, i))
+ continue;
+
+ if (!TEST_HARD_REG_BIT (hard_regs_spilled_into, i))
+ continue;
+
+ if (bitmap_bit_p (df_get_live_in (bb), i))
+ continue;
+
+ live_change_p = true;
+ if (lra_dump_file)
+ fprintf (lra_dump_file,
+ " hard reg r%d is added to live at bb%d start\n", i,
+ bb->index);
+ bitmap_set_bit (df_get_live_in (bb), i);
+ }
+
if (need_curr_point_incr)
next_program_point (curr_point, freq);
@@ -1320,6 +1339,11 @@ lra_create_live_ranges_1 (bool all_p, bool dead_insn_p)
}
/* As we did not change CFG since LRA start we can use
DF-infrastructure solver to solve live data flow problem. */
+ for (int i = 0; i < FIRST_PSEUDO_REGISTER; ++i)
+ {
+ if (TEST_HARD_REG_BIT (hard_regs_spilled_into, i))
+ bitmap_clear_bit (&all_hard_regs_bitmap, i);
+ }
df_simple_dataflow
(DF_BACKWARD, NULL, live_con_fun_0, live_con_fun_n,
live_trans_fun, &all_blocks,
diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index af11b3d..ab13b21 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -291,6 +291,8 @@ assign_spill_hard_regs (int *pseudo_regnos, int n)
}
if (lra_dump_file != NULL)
fprintf (lra_dump_file, " Spill r%d into hr%d\n", regno, hard_regno);
+ add_to_hard_reg_set (&hard_regs_spilled_into,
+ lra_reg_info[regno].biggest_mode, hard_regno);
/* Update reserved_hard_regs. */
for (r = lra_reg_info[regno].live_ranges; r != NULL; r = r->next)
for (p = r->start; p <= r->finish; p++)
diff --git a/gcc/lra.c b/gcc/lra.c
index fec2383..047e64f 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -1270,6 +1270,8 @@ static int reg_info_size;
/* Common info about each register. */
struct lra_reg *lra_reg_info;
+HARD_REG_SET hard_regs_spilled_into;
+
/* Last register value. */
static int last_reg_value;
@@ -1319,6 +1321,7 @@ init_reg_info (void)
for (i = 0; i < reg_info_size; i++)
initialize_lra_reg_info_element (i);
copy_vec.truncate (0);
+ CLEAR_HARD_REG_SET (hard_regs_spilled_into);
}
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2017-12-15 11:26 ` [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs Tom de Vries
@ 2017-12-18 16:57 ` Vladimir Makarov
2018-01-08 16:52 ` Tom de Vries
0 siblings, 1 reply; 11+ messages in thread
From: Vladimir Makarov @ 2017-12-18 16:57 UTC (permalink / raw)
To: Tom de Vries, gcc-patches
On 12/15/2017 06:25 AM, Tom de Vries wrote:
>
> Proposed Solution:
>
> The patch addresses the problem, by:
> - marking the hard regs that have been used in lra_spill in
> Â hard_regs_spilled_into
> - using hard_regs_spilled_into in lra_create_live_ranges to
> Â make sure those registers are marked in the conflict_hard_regs
> Â of pseudos that overlap with the spill register usage
>
> [ I've also tried an approach where I didn't use
> hard_regs_spilled_into, but tried to propagate all hard regs. I
> figured out that I needed to mask out eliminable_regset. Also I
> needed to masked out lra_no_alloc_regs, but that could be due to
> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
> Anyway, in the submitted patch I tried to avoid these problems and
> went for the more minimal approach. ]
>
Tom, thank you for the detail explanation of the problem and solutions
you considered. It helped me a lot. Your simple solution is adequate
as the most transformations and allocation are done on the 1st LRA
subpasses iteration.
> In order to get the patch accepted for trunk, I think we need:
> - bootstrap and reg-test on x86_64
> - build and reg-test on mips (the only primary platform that has the
> Â spill_class hook enabled)
>
> Any comments?
The patch looks ok to me. You can commit it after successful testing on
x86-64 and mips but I am sure there will be no problems with x86-64 as
it does not use spill_class currently (actually your patch might help to
switch it on again for x86-64. spill_class was quite useful for x86-64
performance on Intel processors).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2017-12-18 16:57 ` Vladimir Makarov
@ 2018-01-08 16:52 ` Tom de Vries
2018-02-26 9:32 ` Tom de Vries
0 siblings, 1 reply; 11+ messages in thread
From: Tom de Vries @ 2018-01-08 16:52 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
>
>
> On 12/15/2017 06:25 AM, Tom de Vries wrote:
>>
>> Proposed Solution:
>>
>> The patch addresses the problem, by:
>> - marking the hard regs that have been used in lra_spill in
>> Â hard_regs_spilled_into
>> - using hard_regs_spilled_into in lra_create_live_ranges to
>> Â make sure those registers are marked in the conflict_hard_regs
>> Â of pseudos that overlap with the spill register usage
>>
>> [ I've also tried an approach where I didn't use
>> hard_regs_spilled_into, but tried to propagate all hard regs. I
>> figured out that I needed to mask out eliminable_regset. Also I
>> needed to masked out lra_no_alloc_regs, but that could be due to
>> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
>> Anyway, in the submitted patch I tried to avoid these problems and
>> went for the more minimal approach. ]
>>
> Tom, thank you for the detail explanation of the problem and solutions
> you considered. It helped me a lot. Your simple solution is adequate
> as the most transformations and allocation are done on the 1st LRA
> subpasses iteration.
>> In order to get the patch accepted for trunk, I think we need:
>> - bootstrap and reg-test on x86_64
>> - build and reg-test on mips (the only primary platform that has the
>> Â spill_class hook enabled)
>>
>> Any comments?
>
> The patch looks ok to me. You can commit it after successful testing on
> x86-64 and mips but I am sure there will be no problems with x86-64 as
> it does not use spill_class currently (actually your patch might help to
> switch it on again for x86-64. spill_class was quite useful for x86-64
> performance on Intel processors).
>
Hi Matthew,
there's an lra optimization that is currently enabled for MIPS, and not
for any other primary or secondary target.
This (already approved) patch fixes a bug in that optimization, and
needs to be tested on MIPS.
Unfortunately, the optimization is only enabled for MIPS16, and we don't
have a current setup to test this.
Could you help us out here and test this patch for MIPS16 on trunk?
Thanks,
- Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2018-01-08 16:52 ` Tom de Vries
@ 2018-02-26 9:32 ` Tom de Vries
2018-02-26 11:01 ` Matthew Fortune
0 siblings, 1 reply; 11+ messages in thread
From: Tom de Vries @ 2018-02-26 9:32 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
On 01/08/2018 05:32 PM, Tom de Vries wrote:
> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
>>
>>
>> On 12/15/2017 06:25 AM, Tom de Vries wrote:
>>>
>>> Proposed Solution:
>>>
>>> The patch addresses the problem, by:
>>> - marking the hard regs that have been used in lra_spill in
>>> Â hard_regs_spilled_into
>>> - using hard_regs_spilled_into in lra_create_live_ranges to
>>> Â make sure those registers are marked in the conflict_hard_regs
>>> Â of pseudos that overlap with the spill register usage
>>>
>>> [ I've also tried an approach where I didn't use
>>> hard_regs_spilled_into, but tried to propagate all hard regs. I
>>> figured out that I needed to mask out eliminable_regset. Also I
>>> needed to masked out lra_no_alloc_regs, but that could be due to
>>> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
>>> Anyway, in the submitted patch I tried to avoid these problems and
>>> went for the more minimal approach. ]
>>>
>> Tom, thank you for the detail explanation of the problem and solutions
>> you considered. It helped me a lot. Your simple solution is adequate
>> as the most transformations and allocation are done on the 1st LRA
>> subpasses iteration.
>>> In order to get the patch accepted for trunk, I think we need:
>>> - bootstrap and reg-test on x86_64
>>> - build and reg-test on mips (the only primary platform that has the
>>> Â spill_class hook enabled)
>>>
>>> Any comments?
>>
>> The patch looks ok to me. You can commit it after successful testing
>> on x86-64 and mips but I am sure there will be no problems with x86-64
>> as it does not use spill_class currently (actually your patch might
>> help to switch it on again for x86-64. spill_class was quite useful
>> for x86-64 performance on Intel processors).
>>
>
> Hi Matthew,
>
> there's an lra optimization that is currently enabled for MIPS, and not
> for any other primary or secondary target.
>
> This (already approved) patch fixes a bug in that optimization, and
> needs to be tested on MIPS.
>
> Unfortunately, the optimization is only enabled for MIPS16, and we don't
> have a current setup to test this.
>
> Could you help us out here and test this patch for MIPS16 on trunk?
Hi Matthew,
is this something you can help us out with?
Thanks,
- Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2018-02-26 9:32 ` Tom de Vries
@ 2018-02-26 11:01 ` Matthew Fortune
2018-02-26 13:46 ` Tom de Vries
0 siblings, 1 reply; 11+ messages in thread
From: Matthew Fortune @ 2018-02-26 11:01 UTC (permalink / raw)
To: Tom de Vries; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
Tom de Vries <Tom_deVries@mentor.com> writes:
> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> > On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> >>
> >>
> >> On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >>>
> >>> Proposed Solution:
> >>>
> >>> The patch addresses the problem, by:
> >>> - marking the hard regs that have been used in lra_spill in
> >>> hard_regs_spilled_into
> >>> - using hard_regs_spilled_into in lra_create_live_ranges to
> >>> make sure those registers are marked in the conflict_hard_regs
> >>> of pseudos that overlap with the spill register usage
> >>>
> >>> [ I've also tried an approach where I didn't use
> >>> hard_regs_spilled_into, but tried to propagate all hard regs. I
> >>> figured out that I needed to mask out eliminable_regset. Also I
> >>> needed to masked out lra_no_alloc_regs, but that could be due to
> >>> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
> >>> Anyway, in the submitted patch I tried to avoid these problems and
> >>> went for the more minimal approach. ]
> >>>
> >> Tom, thank you for the detail explanation of the problem and
> >> solutions you considered. It helped me a lot. Your simple solution
> >> is adequate as the most transformations and allocation are done on
> >> the 1st LRA subpasses iteration.
> >>> In order to get the patch accepted for trunk, I think we need:
> >>> - bootstrap and reg-test on x86_64
> >>> - build and reg-test on mips (the only primary platform that has the
> >>> spill_class hook enabled)
> >>>
> >>> Any comments?
> >>
> >> The patch looks ok to me. You can commit it after successful testing
> >> on x86-64 and mips but I am sure there will be no problems with
> >> x86-64 as it does not use spill_class currently (actually your patch
> >> might help to switch it on again for x86-64. spill_class was quite
> >> useful for x86-64 performance on Intel processors).
> >>
> >
> > Hi Matthew,
> >
> > there's an lra optimization that is currently enabled for MIPS, and
> > not for any other primary or secondary target.
> >
> > This (already approved) patch fixes a bug in that optimization, and
> > needs to be tested on MIPS.
> >
> > Unfortunately, the optimization is only enabled for MIPS16, and we
> > don't have a current setup to test this.
> >
> > Could you help us out here and test this patch for MIPS16 on trunk?
>
> Hi Matthew,
>
> is this something you can help us out with?
Hi Tom,
I've just commented on the bug report that I've set of some builds to try
and give some assurance. It is far from comprehensive but it is as good as
the normal testing I do for MIPS16.
Thanks,
Matthew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2018-02-26 11:01 ` Matthew Fortune
@ 2018-02-26 13:46 ` Tom de Vries
2018-02-26 14:17 ` Matthew Fortune
2018-02-28 22:18 ` Matthew Fortune
0 siblings, 2 replies; 11+ messages in thread
From: Tom de Vries @ 2018-02-26 13:46 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
On 02/26/2018 12:00 PM, Matthew Fortune wrote:
> Tom de Vries <Tom_deVries@mentor.com> writes:
>> On 01/08/2018 05:32 PM, Tom de Vries wrote:
>>> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
>>>>
>>>>
>>>> On 12/15/2017 06:25 AM, Tom de Vries wrote:
>>>>>
>>>>> Proposed Solution:
>>>>>
>>>>> The patch addresses the problem, by:
>>>>> - marking the hard regs that have been used in lra_spill in
>>>>> Â hard_regs_spilled_into
>>>>> - using hard_regs_spilled_into in lra_create_live_ranges to
>>>>> Â make sure those registers are marked in the conflict_hard_regs
>>>>> Â of pseudos that overlap with the spill register usage
>>>>>
>>>>> [ I've also tried an approach where I didn't use
>>>>> hard_regs_spilled_into, but tried to propagate all hard regs. I
>>>>> figured out that I needed to mask out eliminable_regset. Also I
>>>>> needed to masked out lra_no_alloc_regs, but that could be due to
>>>>> gcn-specific problems (pointers take 2 hard regs), I'm not yet sure.
>>>>> Anyway, in the submitted patch I tried to avoid these problems and
>>>>> went for the more minimal approach. ]
>>>>>
>>>> Tom, thank you for the detail explanation of the problem and
>>>> solutions you considered. It helped me a lot. Your simple solution
>>>> is adequate as the most transformations and allocation are done on
>>>> the 1st LRA subpasses iteration.
>>>>> In order to get the patch accepted for trunk, I think we need:
>>>>> - bootstrap and reg-test on x86_64
>>>>> - build and reg-test on mips (the only primary platform that has the
>>>>> Â spill_class hook enabled)
>>>>>
>>>>> Any comments?
>>>>
>>>> The patch looks ok to me. You can commit it after successful testing
>>>> on x86-64 and mips but I am sure there will be no problems with
>>>> x86-64 as it does not use spill_class currently (actually your patch
>>>> might help to switch it on again for x86-64. spill_class was quite
>>>> useful for x86-64 performance on Intel processors).
>>>>
>>>
>>> Hi Matthew,
>>>
>>> there's an lra optimization that is currently enabled for MIPS, and
>>> not for any other primary or secondary target.
>>>
>>> This (already approved) patch fixes a bug in that optimization, and
>>> needs to be tested on MIPS.
>>>
>>> Unfortunately, the optimization is only enabled for MIPS16, and we
>>> don't have a current setup to test this.
>>>
>>> Could you help us out here and test this patch for MIPS16 on trunk?
>>
>> Hi Matthew,
>>
>> is this something you can help us out with?
>
> Hi Tom,
>
> I've just commented on the bug report that I've set of some builds to try
> and give some assurance. It is far from comprehensive but it is as good as
> the normal testing I do for MIPS16.
>
Hi Matthew,
Awesome, thanks for the help.
- Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2018-02-26 13:46 ` Tom de Vries
@ 2018-02-26 14:17 ` Matthew Fortune
2018-02-28 22:18 ` Matthew Fortune
1 sibling, 0 replies; 11+ messages in thread
From: Matthew Fortune @ 2018-02-26 14:17 UTC (permalink / raw)
To: Tom de Vries; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
Tom de Vries <Tom_deVries@mentor.com> writes:
> On 02/26/2018 12:00 PM, Matthew Fortune wrote:
> > Tom de Vries <Tom_deVries@mentor.com> writes:
> >> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> >>> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> >>>>
> >>>>
> >>>> On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >>>>>
> >>>>> Proposed Solution:
> >>>>>
> >>>>> The patch addresses the problem, by:
> >>>>> - marking the hard regs that have been used in lra_spill in
> >>>>> hard_regs_spilled_into
> >>>>> - using hard_regs_spilled_into in lra_create_live_ranges to
> >>>>> make sure those registers are marked in the conflict_hard_regs
> >>>>> of pseudos that overlap with the spill register usage
> >>>>>
> >>>>> [ I've also tried an approach where I didn't use
> >>>>> hard_regs_spilled_into, but tried to propagate all hard regs. I
> >>>>> figured out that I needed to mask out eliminable_regset. Also I
> >>>>> needed to masked out lra_no_alloc_regs, but that could be due to
> >>>>> gcn-specific problems (pointers take 2 hard regs), I'm not yet
> sure.
> >>>>> Anyway, in the submitted patch I tried to avoid these problems and
> >>>>> went for the more minimal approach. ]
> >>>>>
> >>>> Tom, thank you for the detail explanation of the problem and
> >>>> solutions you considered. It helped me a lot. Your simple
> >>>> solution is adequate as the most transformations and allocation are
> >>>> done on the 1st LRA subpasses iteration.
> >>>>> In order to get the patch accepted for trunk, I think we need:
> >>>>> - bootstrap and reg-test on x86_64
> >>>>> - build and reg-test on mips (the only primary platform that has
> >>>>> the
> >>>>> spill_class hook enabled)
> >>>>>
> >>>>> Any comments?
> >>>>
> >>>> The patch looks ok to me. You can commit it after successful
> >>>> testing on x86-64 and mips but I am sure there will be no problems
> >>>> with
> >>>> x86-64 as it does not use spill_class currently (actually your
> >>>> patch might help to switch it on again for x86-64. spill_class was
> >>>> quite useful for x86-64 performance on Intel processors).
> >>>>
> >>>
> >>> Hi Matthew,
> >>>
> >>> there's an lra optimization that is currently enabled for MIPS, and
> >>> not for any other primary or secondary target.
> >>>
> >>> This (already approved) patch fixes a bug in that optimization, and
> >>> needs to be tested on MIPS.
> >>>
> >>> Unfortunately, the optimization is only enabled for MIPS16, and we
> >>> don't have a current setup to test this.
> >>>
> >>> Could you help us out here and test this patch for MIPS16 on trunk?
> >>
> >> Hi Matthew,
> >>
> >> is this something you can help us out with?
> >
> > Hi Tom,
> >
> > I've just commented on the bug report that I've set of some builds to
> > try and give some assurance. It is far from comprehensive but it is as
> > good as the normal testing I do for MIPS16.
> >
>
> Hi Matthew,
>
> Awesome, thanks for the help.
I'm afraid my lack of attention has shown that there appears to be a
bug preventing libstdc++ building with MIPS16 that was introduced
somewhere between Oct 9th and Oct 10th. 47 commits left to bisect.
Matthew
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs
2018-02-26 13:46 ` Tom de Vries
2018-02-26 14:17 ` Matthew Fortune
@ 2018-02-28 22:18 ` Matthew Fortune
1 sibling, 0 replies; 11+ messages in thread
From: Matthew Fortune @ 2018-02-28 22:18 UTC (permalink / raw)
To: Tom de Vries; +Cc: Vladimir Makarov, gcc-patches, Moore, Catherine
Tom de Vries <Tom_deVries@mentor.com> writes:
> On 02/26/2018 12:00 PM, Matthew Fortune wrote:
> > Tom de Vries <Tom_deVries@mentor.com> writes:
> >> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> >>> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> >>>>
> >>>>
> >>>> On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >>>>>
> >>>>> Proposed Solution:
> >>>>>
> >>>>> The patch addresses the problem, by:
> >>>>> - marking the hard regs that have been used in lra_spill in
> >>>>> hard_regs_spilled_into
> >>>>> - using hard_regs_spilled_into in lra_create_live_ranges to
> >>>>> make sure those registers are marked in the conflict_hard_regs
> >>>>> of pseudos that overlap with the spill register usage
> >>>>>
> >>>>> [ I've also tried an approach where I didn't use
> >>>>> hard_regs_spilled_into, but tried to propagate all hard regs. I
> >>>>> figured out that I needed to mask out eliminable_regset. Also I
> >>>>> needed to masked out lra_no_alloc_regs, but that could be due to
> >>>>> gcn-specific problems (pointers take 2 hard regs), I'm not yet
> sure.
> >>>>> Anyway, in the submitted patch I tried to avoid these problems
> and
> >>>>> went for the more minimal approach. ]
> >>>>>
> >>>> Tom, thank you for the detail explanation of the problem and
> >>>> solutions you considered. It helped me a lot. Your simple
> solution
> >>>> is adequate as the most transformations and allocation are done on
> >>>> the 1st LRA subpasses iteration.
> >>>>> In order to get the patch accepted for trunk, I think we need:
> >>>>> - bootstrap and reg-test on x86_64
> >>>>> - build and reg-test on mips (the only primary platform that has
> the
> >>>>> spill_class hook enabled)
> >>>>>
> >>>>> Any comments?
> >>>>
> >>>> The patch looks ok to me. You can commit it after successful
> testing
> >>>> on x86-64 and mips but I am sure there will be no problems with
> >>>> x86-64 as it does not use spill_class currently (actually your
> patch
> >>>> might help to switch it on again for x86-64. spill_class was
> quite
> >>>> useful for x86-64 performance on Intel processors).
> >>>>
> >>>
> >>> Hi Matthew,
> >>>
> >>> there's an lra optimization that is currently enabled for MIPS, and
> >>> not for any other primary or secondary target.
> >>>
> >>> This (already approved) patch fixes a bug in that optimization, and
> >>> needs to be tested on MIPS.
> >>>
> >>> Unfortunately, the optimization is only enabled for MIPS16, and we
> >>> don't have a current setup to test this.
> >>>
> >>> Could you help us out here and test this patch for MIPS16 on trunk?
> >>
> >> Hi Matthew,
> >>
> >> is this something you can help us out with?
> >
> > Hi Tom,
> >
> > I've just commented on the bug report that I've set of some builds to
> try
> > and give some assurance. It is far from comprehensive but it is as
> good as
> > the normal testing I do for MIPS16.
> >
>
> Hi Matthew,
>
> Awesome, thanks for the help.
I have tested trunk with and without the patch and can confirm there
is no change in test status for MIPS16 big endian.
I ended up fixing an assert-checking issue in the MIPS backend and
a bug (I think) in the C++ frontend to get to the point of testing so
quite a worthwhile effort all in all.
Thanks,
Matthew
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-02-28 22:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-16 20:39 patch to fix PR82353 Vladimir Makarov
2017-12-13 12:35 ` Tom de Vries
2017-12-14 17:01 ` Vladimir Makarov
2017-12-15 11:26 ` [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs Tom de Vries
2017-12-18 16:57 ` Vladimir Makarov
2018-01-08 16:52 ` Tom de Vries
2018-02-26 9:32 ` Tom de Vries
2018-02-26 11:01 ` Matthew Fortune
2018-02-26 13:46 ` Tom de Vries
2018-02-26 14:17 ` Matthew Fortune
2018-02-28 22:18 ` Matthew Fortune
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).