[LLVMdev] Possible bug in SimpleRegisterCoalescing

[Jakob Stoklund Olesen]

On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote:

> While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets.
> 
> I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable registers for each register class are initialised for the function, i.e. the lines: 
> 
>  for (TargetRegisterInfo::regclass_iterator I = tri_->regclass_begin(),
>         E = tri_->regclass_end(); I != E; ++I)
>    allocatableRCRegs_.insert(std::make_pair(*I,
>                                             tri_->getAllocatableSet(fn, *I)));
> 
> If the allocatable registers are dependent on the function, such as might occur when a frame pointer isn't required, then it seems that every function will use the same allocatable set as the first function. [ a DenseMap insert operation has no effect if the key is already present ]

As Eric said, this code is completely different on trunk.

Specifically, the RegisterClassInfo class now caches this information.  It does cache information between functions, but it should invalidate the cache when the set of reserved registers change:

  // Different reserved registers?
  BitVector RR = TRI->getReservedRegs(*MF);
  if (RR != Reserved)
    Update = true;
  Reserved = RR;

  // Invalidate cached information from previous function.
  if (Update)
    ++Tag;

Please verify that it works, though.  As you can see, the set of reserved registers doesn't normally change.

/jakob