This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch to simplify reload register allocation


>   > This algorithm is not completely fail-safe, however.  Consider this
>   > scenario:
>   >   * four registers: r0 .. r3
>   >   * two classes: low_regs (r0 and r1) and all_regs (all four regs)
>   >   * a group reload for class all_regs, and a single register reload for
>   >     low_regs
>   > Since reload_reg_class_lower puts the group reload in front of the other
>   > one we might end up grabbing r0 and r1 for the group, leaving nothing for
>   > the single register reload.  I don't see any attempts to handle this case
>   > in the current code, so I'm not sure this is an issue with any of the
>   > existing ports.
> 
> Isn't this what the "nongroup needs" code is all about?
> 
>   > I'm not entirely sure what the force_group code in allocate_reload_regs is
>   > supposed to do.  Probably it can now go away, since we can always provide a
>   > safe allocation at this point.
> 
> I believe it's related to the case you mention!

Here's the situation as I understand it:
We have two conflicting goals when ordering reloads for allocation.  Either we
put groups ahead to avoid breaking up all possible groups while allocating
smaller reloads, or we sort strictly by increasing register class to avoid
selecting all registers in a small class for a group reload in a larger class.
Currently, the first pass uses the second approach, and the second pass uses
the first approach.  I think (although I could be wrong, this stuff isn't
documented well) that the counted_for_{group,nongroup} sets are used to ensure
that despite the difference in the order in which reload regs are allocated,
the second pass will still find a valid allocation.  The force_group code
appears to be a kludge that works around a problem with that approach, but
it's hard to tell as well.

It's possible that the current setup avoids the problem I described, but if it
does it's probably by accident, not by design.  I think it could be fixed
rather easily if it does show up on some port by modifying the algorithm used
by find_reload_reg (which uses the first approach as described above, i.e.
allocates groups first) in my patch to do something like
  walk reloads in computed order
  if we find a single-reg reload in a small class that is already used up
  completely by a multi-reg reload in a larger class, mark the registers
  from the smaller class as undesirable for the earlier group reload, and
  retry from start

Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]