I'm forwarding this to llvmdev so it doesn't get lost in the sea of commits...
-Dave
reg_iterators are independent of SSA or not. The basic issue is that if you loop over uses or defs of a register, it will return *all* the uses/defs of that register in the current function. If the value is SSA form, it is reasonable to say "give me the first def" and expect it to be the only def. For multiply defined values like physregs, this is not true, because the reg can have multiple defs.
That said, ref_iterator and variants will always do what they are documented to, they just don't magically provide ssa-like properties for physregs.
-Chris
Gotcha. This is exactly what I want. Thanks for the explanation.
For non-SSA values, is there some indication of which defs reach which
uses? I don't need this right now but I can imagine using it in the future.
-Dave
The reg def/kill/dead flags are all that there is.
-Chris
I just discovered that def_itterator (and presumably, reg_iterator) doesn't
include implicit defs, for example at function calls for caller-save physical
registers. Guh. I'm not sure if it should or not, but it's certainly
necessary information in some cases. Is this expected behavior, or an
oversight?
-Dave
SSA form, it is reasonable to say "give me the first def" and expect
it to be the only def. For multiply defined values like physregs,
this is not true, because the reg can have multiple defs.Gotcha. This is exactly what I want. Thanks for the explanation.
For non-SSA values, is there some indication of which defs reach which
uses? I don't need this right now but I can imagine using it in the
future.The reg def/kill/dead flags are all that there is.
I just discovered that def_itterator (and presumably, reg_iterator) doesn't
include implicit defs, for example at function calls for caller-save physical
registers. Guh. I'm not sure if it should or not, but it's certainly
necessary information in some cases. Is this expected behavior, or an
oversight?
MachineRegisterInfo tracks virtual register only.
I also wish it would track physical register defs and uses as well. It can be used to simplify a lot of code (in livevariable, etc.). Chris, do you think that's feasible?
Evan
I just discovered that def_itterator (and presumably, reg_iterator)
doesn't
include implicit defs, for example at function calls for caller-save
physical
registers. Guh. I'm not sure if it should or not, but it's certainly
necessary information in some cases. Is this expected behavior, or an
oversight?
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.
MachineRegisterInfo tracks virtual register only.
It works for vregs and pregs today.
I also wish it would track physical register defs and uses as well. It
can be used to simplify a lot of code (in livevariable, etc.). Chris,
do you think that's feasible?
Really really feasible 
-Chris
I just discovered that def_itterator (and presumably, reg_iterator)
doesn't
include implicit defs, for example at function calls for caller-save
physical
registers. Guh. I'm not sure if it should or not, but it's certainly
necessary information in some cases. Is this expected behavior, or an
oversight?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.MachineRegisterInfo tracks virtual register only.
It works for vregs and pregs today.
Ok! Fooled me with this comment:
/// MachineRegisterInfo - Keep track of information for each virtual register,
/// including its register class.
Evan
Hrm, my tree [now] says:
/// MachineRegisterInfo - Keep track of information for virtual and physical
/// registers, including vreg register classes, use/def chains for registers,
/// etc.
maybe you need to update 
-Chris
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.
We have a very old copy of llvm. Is it possible they got added sometime
after reg_iterators were created?
Also, just as a point of information, where would I go to find out if a
physical register is a caller-save or callee-save register? The closest
thing I can find is in the .td files but no interface is generated (as far
as I can tell) to categorize physical registers according to calling
convention.
-Dave
Urk. It seems things are worse than that, even.
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.
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?
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.
-Dave
I just discovered that def_itterator (and presumably, reg_iterator)
doesn't
include implicit defs, for example at function calls for caller-save
physical
registers. Guh. I'm not sure if it should or not, but it's certainly
necessary information in some cases. Is this expected behavior, or an
oversight?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.We have a very old copy of llvm. Is it possible they got added sometime
after reg_iterators were created?
Not sure.
Also, just as a point of information, where would I go to find out if a
physical register is a caller-save or callee-save register? The closest
thing I can find is in the .td files but no interface is generated (as far
as I can tell) to categorize physical registers according to calling
convention.
See X86RegisterInfo::getCalleeSavedRegs() etc.
Evan
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 have.
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.
-Chris
>>> 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
have.
Yep, it's on my TODO list.
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.
Ok, I see the code in MachineOperand to do this. Strange. I've hacked around
it for the time being. I'll double-check when we update.
-Dave