public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/85072] g++ -O1 consumes all memory
       [not found] <bug-85072-4@http.gcc.gnu.org/bugzilla/>
@ 2024-02-19 13:01 ` rguenth at gcc dot gnu.org
  0 siblings, 0 replies; only message in thread
From: rguenth at gcc dot gnu.org @ 2024-02-19 13:01 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-02-19 13:01 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-85072-4@http.gcc.gnu.org/bugzilla/>
2024-02-19 13:01 ` [Bug rtl-optimization/85072] g++ -O1 consumes all memory rguenth at gcc dot gnu.org

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).