https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85072
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2018-03-26 00:00:00 |2024-2-19
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, I was (probably) wanting to say the patch doesn't help.
I think the issue is that we have many "live points" and each one is
covered by at least one reg. Classical quadratic case.
The question is why live_reload_and_inheritance_pseudo is needed at all
(it seems like a cache). But the single use has no comments and it's
impossible for anybody but the author to decipher what exactly
for (r = lra_reg_info[regno].live_ranges; r != NULL; r = r->next)
{
EXECUTE_IF_SET_IN_BITMAP (&live_hard_reg_pseudos[r->start], 0, k, bi)
if (rclass_intersect_p[regno_allocno_class_array[k]])
sparseset_set_bit (live_range_hard_reg_pseudos, k);
EXECUTE_IF_SET_IN_BITMAP (&live_reload_and_inheritance_pseudos[r->start],
0, k, bi)
if (lra_reg_info[k].preferred_hard_regno1 >= 0
&& live_pseudos_reg_renumber[k] < 0
&& rclass_intersect_p[regno_allocno_class_array[k]])
sparseset_set_bit (conflict_reload_and_inheritance_pseudos, k);
...
tries to compute. I suspect the data structure is not the best for this
degenerate case at least. Given the above looks at 'regno' live ranges
it seems it maybe wants to compute the set of live "reload and inheritance"
pseudos in those ranges (but curiously we only look at r->start for each
subrange). Then there's the following mysterious loop that possibly
deals with r->start + 1 to r->finish, but not using that cache bitmaps
at all ...
Re-confirmed on trunk. LRA is very slow and memory hungry at -O1 here.
