llvm dev - Feb 2013 - [LLVMdev] implicit register usage

On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote:
> I'm not sure. It certainly seems reasonable to me that the building
could/should set default Define flags on operands based on the MCInstrDesc.
Dunno why it doesn't.
Once you move beyond the fixed operands, it can't be determined
automatically if the added register should be a use or a def.

But I think it would be convenient to add addUse() and addDef() methods to
MachineInstrBuilder, instead of requiring the tedious addReg(...,
RegState::Define).

/jakob

On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
wrote:
> 
> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com>
wrote:
> 
>> I'm not sure. It certainly seems reasonable to me that the building
could/should set default Define flags on operands based on the MCInstrDesc.
Dunno why it doesn't.
> 
> Once you move beyond the fixed operands, it can't be determined
automatically if the added register should be a use or a def.
Yes, very true. It seems the builder should use the information for the fixed
operands, though? Or at least perhaps the machine verifier should check that
they match what's actually on the operands (does it currently?). Right now
it's pretty easy to construct an MI that's inconsistent with its
MCInstrDesc information.
-Jim
> 
> But I think it would be convenient to add addUse() and addDef() methods to
MachineInstrBuilder, instead of requiring the tedious addReg(...,
RegState::Define).
> 
> /jakob
>

On Feb 20, 2013, at 1:27 PM, Jim Grosbach <grosbach at apple.com> wrote:
> 
> On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
> 
>> 
>> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at
apple.com> wrote:
>> 
>>> I'm not sure. It certainly seems reasonable to me that the
building could/should set default Define flags on operands based on the
MCInstrDesc. Dunno why it doesn't.
>> 
>> Once you move beyond the fixed operands, it can't be determined
automatically if the added register should be a use or a def.
> 
> Yes, very true. It seems the builder should use the information for the
fixed operands, though? Or at least perhaps the machine verifier should check
that they match what's actually on the operands (does it currently?). Right
now it's pretty easy to construct an MI that's inconsistent with its
MCInstrDesc information.
The verifier checks uses and defs when it can (i.e., the fixed ops).

I am not a big fan of automagic features that only work some of the time. You
tend to rely on them and not notice when they fail. They should at least fail
loudly then.

Imagine if Tablegen would infer the attributes of instructions most of the time,
but just revert to guessing when the inference fails. We would get all kinds of
weird attributes on our instructions without even noticing. Crazy! ;)

Are there cases where code calls BuildMI().addReg() without knowing if it is
adding a use or a def? That seems like it would be rare.

We could add assertions inside MachineInstr::addOperand() to check the uses and
defs against the MCInstrDesc. We do have code, though, that modifies an
instruction in place before swizzling the descriptor. Such code could be fixed,
I guess.

/jakob