[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
compile-time is back to the first jump caused by r14-2337-g37a231cc7594d1,
thanks Roger.  We still have

 LRA non-specific                   :   3.53 ( 75%)

at -O0 here which Rogers followup patch will improve (but not generally
solve the issue).

At -O1 combine dominates, at -O2 we see other parts of RA being slow:

 integrated RA                      :   7.10 ( 23%) 
 LRA non-specific                   :   1.56 (  5%)
 LRA virtuals elimination           :   0.07 (  0%)
 LRA reload inheritance             :   1.02 (  3%)
 LRA create live ranges             :   0.88 (  3%)
 LRA hard reg assignment            :   8.22 ( 27%)
 LRA coalesce pseudo regs           :   0.00 (  0%)
 LRA rematerialization              :   0.18 (  1%)

Samples: 124K of event 'cycles:u', Event count (approx.): 164730867020          
Overhead       Samples  Command  Shared Object       Symbol                     
  16.60%         20660  cc1      cc1                 [.] find_hard_regno_for_1
  11.90%         14742  cc1      cc1                 [.] bitmap_set_bit
   6.47%          7973  cc1      cc1                 [.] color_allocnos
   3.31%          4023  cc1      cc1                 [.] bitmap_bit_p
   3.07%          3791  cc1      cc1                 [.]
remove_allocno_from_bucket_and_push
   2.77%          3435  cc1      cc1                 [.] assign_hard_reg
   2.54%          3138  cc1      cc1                 [.] ira_build_conflicts

in find_hard_regno_for_1 the loop over live ranges is what's costly, esp.
because it seems the conditionals in the loops depend on (indirect) memory
and that no longer fits nicely into caches.

Maybe regno_allocno_class_array can be shrunk from 'enum reg_class'
(unsigned int) to something smaller.  It looks like this array is a
memory optimization since reg_allocno_class would perform a much sparser
access.