[LLVMdev] implicit register usage

[reed kotler]

If I put in my tablegen td file that a certain instruction implicitly
sets a register, do I need to also do the same if I am using BuildMI or
can I assume that further passes and such will now know that this
register is implicitly set or used?

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jim Grosbach]

Hi Reed,

The .td file "Defs = …" should be sufficient. The implicit uses and implicit defs are part of the MCInstrDesc data structure, which is shared by all instances of a given instruction.

-Jim

[reed kotler]

Hi Jim,

One thing that seems strange to me is that if do a BuildMI, if you put a
register inside the first parens, then it will treat it as a def, but if
you just .addReg it won't (by default), even though it should know from
the instruction definition.

Seems like it should do that.

Why would you want it to not do that?

Reed

[Jim Grosbach]

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.

-Jim

[Jakob Stoklund Olesen]

On Feb 20, 2013, at 11:44 AM, Jim Grosbach <gros...@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

[Jim Grosbach]

On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stok...@2pi.dk> wrote:

>
> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <gros...@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

[Jakob Stoklund Olesen]

On Feb 20, 2013, at 1:27 PM, Jim Grosbach <gros...@apple.com> wrote:

>
> On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stok...@2pi.dk> wrote:
>
>>
>> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <gros...@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.

[Jim Grosbach]

On Feb 20, 2013, at 1:46 PM, Jakob Stoklund Olesen <stok...@2pi.dk> wrote:

>
> On Feb 20, 2013, at 1:27 PM, Jim Grosbach <gros...@apple.com> wrote:
>
>>
>> On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stok...@2pi.dk> wrote:
>>
>>>
>>> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <gros...@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).

OK, cool. That alleviates the vast majority of my concern.

> 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.

That's an entirely fair argument.

> 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! ;)
>

Touche, sir!

> 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.
>

Yeah, it's pretty rare. I'm unconvinced there would realistically be cases that both don't know and can't be taught to know.

> 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.

Yeah, switching the description is a touchy one. We take advantage of that a fair bit. On the other hand, I don't know that we ever do it in a situation that would change the Def flags.

I like the idea of adding assert()s to validate.

-Jim