[LLVMdev] reg_iterator Caveats

Chris Lattner sabre at nondot.org
Tue Apr 1 10:35:14 PDT 2008

On Tue, 1 Apr 2008, David Greene wrote:
> On Tuesday 01 April 2008 10:47, David Greene wrote:
>>> reg iterators will return everything that is in the function.  If the
>>> implicit operands haven't been added to the machieninstrs yet, then they
>>> won't be returned.
>> Hmm...this is definitely NOT true in my copy.  During register allocation
>> these implicit defs are not returned.  By then the instructions are most
>> definitely fully constructed.  :)
> Urk.  It seems things are worse than that, even.

You should try updating to mainline.  I have no idea what snapshot you 

Barring a serious bug, the use/def chains cannot get out of date.  When a 
machineinstr is inserted into a function or when an operand is added to 
the instr, it is automatically added to the register list.  There is no 
way that these can get out of date, by design.

> By the time things hit regalloc, the def/use lists seem to be completely
> out of date.  Instructions that exist in the function are not reflected in the
> def lists, for example.  Simple register-to-register copies are completely
> missed.  So far I've only discovered this to be the case for physical
> registers, though that doesn't mean virtual register information isn't also
> out of date.

You'd have to debug it.

> Who constructs this information?  I don't see any interfaces in
> MachineRegisterInfo to keep the information up to date as instructions
> are added or deleted.  Do I need to depend on some Pass?

It is implicitly always up to date.  Start looking at 
MachineOperand::setReg for example to see what happens when you change the 
register an operand refers to.

> What does coalescing do with this information?  Does it update it as
> intervals are merged and instructions are changed?  I thought
> MachineRegisterInfo::replaceRegWith might handle this but it doesn't
> update MachineRegisterInfo::VRegInfo.

No passes need to update this info explicitly.



More information about the llvm-dev mailing list