This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Rename `MachineInstr::defs` to `MachineInstr::explicit_defs` (NFC)
AcceptedPublic

Authored by barannikov88 on May 18 2023, 6:20 AM.

Details

Summary

defs and uses are two misnomers that have a very high potential of introducing bugs.
This patch deals with defs by giving it a proper name explicit_defs.
It is more difficult to find an appropriate name for uses, leave it as it is for now.
(uses returns explicit uses plus all implicit operands, including implicit defs.)

Diff Detail

Event Timeline

barannikov88 created this revision.May 18 2023, 6:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 18 2023, 6:20 AM
barannikov88 edited the summary of this revision. (Show Details)May 18 2023, 6:24 AM
barannikov88 edited the summary of this revision. (Show Details)May 18 2023, 6:28 AM
barannikov88 edited the summary of this revision. (Show Details)
barannikov88 published this revision for review.May 18 2023, 6:31 AM
barannikov88 edited the summary of this revision. (Show Details)
barannikov88 edited the summary of this revision. (Show Details)
barannikov88 added reviewers: craig.topper, arsenm, foad.
barannikov88 retitled this revision from [CodeGen] Rename `MachineInstr::defs` to `MachineInstr::explicit_defs` to [CodeGen] Rename `MachineInstr::defs` to `MachineInstr::explicit_defs` (NFC).May 18 2023, 6:32 AM
barannikov88 edited the summary of this revision. (Show Details)

Update SPIRV

foad accepted this revision.May 19 2023, 1:05 AM

This makes a lot of sense to me.

It is more difficult to find an appropriate name for uses

Agreed. Maybe the solution is to remove uses? How "useful" is it? Can we migrate to operands and/or implicit_operands?

This revision is now accepted and ready to land.May 19 2023, 1:05 AM

This makes a lot of sense to me.

It is more difficult to find an appropriate name for uses

Agreed. Maybe the solution is to remove uses? How "useful" is it? Can we migrate to operands and/or implicit_operands?

I tried, but it is not always obvious from the context what would be the correct change.
I got the impression that you are familiar with AMDGPU (it is one of the main consumers of defs()/uses(), as the diff shows),
so maybe you could handle this part?

foad added a comment.May 19 2023, 2:44 AM

This makes a lot of sense to me.

It is more difficult to find an appropriate name for uses

Agreed. Maybe the solution is to remove uses? How "useful" is it? Can we migrate to operands and/or implicit_operands?

I tried, but it is not always obvious from the context what would be the correct change.
I got the impression that you are familiar with AMDGPU (it is one of the main consumers of defs()/uses(), as the diff shows),
so maybe you could handle this part?

Sure, I can help, but I can't promise how much time I can spend on it.

I see this sort of pattern a few times:

for (auto &MO : I->uses()) {
  if (MO.isReg() && MO.isUse()) {
    MRI.clearKillFlags(MO.getReg());
  }
}

Here we could really use a proper uses (or maybe all_uses) iterator that does the filtering for us, so it returns all use operands and only the use operands.

Do you think it would be worth renaming the current uses to something ugly like uses_and_implicit_operands, in the hope of migrating all users to something less ugly and then removing it?

barannikov88 added a comment.EditedMay 19 2023, 3:06 AM

Sure, I can help, but I can't promise how much time I can spend on it.

Thanks! There is no hurry.

I see this sort of pattern a few times:

for (auto &MO : I->uses()) {
  if (MO.isReg() && MO.isUse()) {
    MRI.clearKillFlags(MO.getReg());
  }
}

Here we could really use a proper uses (or maybe all_uses) iterator that does the filtering for us, so it returns all use operands and only the use operands.

Do you think it would be worth renaming the current uses to something ugly like uses_and_implicit_operands, in the hope of migrating all users to something less ugly and then removing it?

SGTM assuming we provide a replacement for cases where we only need uses (explicit + implicit).
uses() would be a natural choise for this, but changing its behavior silently will cause problems to downstream users.
Either some time should pass before we can re-introduce uses() or a different name should be picked (all_uses() sounds good to me as well).

BTW should uses() be deprecated instead of removed in this patch?

foad added a comment.May 19 2023, 3:14 AM

Sure, I can help, but I can't promise how much time I can spend on it.

Thanks! There is no hurry.

I see this sort of pattern a few times:

for (auto &MO : I->uses()) {
  if (MO.isReg() && MO.isUse()) {
    MRI.clearKillFlags(MO.getReg());
  }
}

Here we could really use a proper uses (or maybe all_uses) iterator that does the filtering for us, so it returns all use operands and only the use operands.

Do you think it would be worth renaming the current uses to something ugly like uses_and_implicit_operands, in the hope of migrating all users to something less ugly and then removing it?

SGTM assuming we provide a replacement for cases where we only need uses (explicit + implicit).
uses() would be a natural choise for this, but changing its behavior silently will cause problems to downstream users.
Either some time should pass before we can re-introduce uses() or a different name should be picked (all_uses() sounds good to me as well).

BTW should uses() be deprecated instead of removed in this patch?

If we implement all_uses (and all_defs?) then maybe there is no need to rename uses after all. In the future hopefully we can deprecate and then remove it.

If we implement all_uses (and all_defs?) then maybe there is no need to rename uses after all.

Good point.
I'll create a discourse topic to see how people feel about all_uses/all_defs.