This is an archive of the discontinued LLVM Phabricator instance.

[MachineInstr] Introduce TII buildCopy helper functions (NFC).
AbandonedPublic

Authored by cdevadas on Feb 10 2023, 9:17 AM.

Diff Detail

Event Timeline

cdevadas created this revision.Feb 10 2023, 9:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2023, 9:17 AM
Herald added subscribers: tpr, hiraditya. · View Herald Transcript
cdevadas requested review of this revision.Feb 10 2023, 9:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2023, 9:17 AM

Hey,

What's the long term plan for this helper?

I am not mad at the refactoring itself, but I'm wondering what kind of criteria we should use to decide when we add such helper.

For instance, should we do the same thing for PHI, INSERT_SUBREG, etc. and why or why not.
Also, should these helper be virtual or not?

I guess where I am going is what do you intend to simplify/achieve with them?

The bottom line is without a proper rationale on why we need this helper, I feel that it gets difficult to know which method should be used to construct a copy.
Right now we have BuildMI (and the underlying MachineInstrBuilder object that can be called directly), MachineFunction::CreateMachineInstr, MachineIRBuilder::buildInstr (BTW MachineIRBuilder has its own MachineIRBuilder::buildCopy) and we add a new method here.

I believe we need to disambiguate when this one should be used and why.

Admittedly I'm playing the devil's advocate here (I actually like the patch) but I think it is important to flush out the goals and intended usages to be able to better guide future users of this (and the other) API(s).

Cheers,
-Quentin

Hey,

What's the long term plan for this helper?

I am not mad at the refactoring itself, but I'm wondering what kind of criteria we should use to decide when we add such helper.

The real motivation for these buildCopy helper functions is to minimize the additional code changes required while introducing getCopyOpcode() as part of D143754.
One could probably say that "still you could have avoided the buildCopy functions, and instead replace TargetOpcode::COPY with getCopyOpcode()".
I think it would be ok to refactor the code if found an opportunity while working around that code.

For instance, should we do the same thing for PHI, INSERT_SUBREG, etc. and why or why not.
Also, should these helper be virtual or not?

As I said earlier, COPY wasn't a random pick, but rather a code refactor for another patch.

I guess where I am going is what do you intend to simplify/achieve with them?

I felt it was better with buildCopy rather than the direct replacement of TargetOpcode::COPY with getCopyOpcode() in their original BuildMI instances. You tend to agree with that towards the end - "(I actually like the patch)".

The bottom line is without a proper rationale on why we need this helper, I feel that it gets difficult to know which method should be used to construct a copy.
Right now we have BuildMI (and the underlying MachineInstrBuilder object that can be called directly), MachineFunction::CreateMachineInstr, MachineIRBuilder::buildInstr (BTW MachineIRBuilder has its own MachineIRBuilder::buildCopy) and we add a new method here.

I agree. All my buildCopy instances currently return MachineInstr*. I wasn't sure they should return MachineInstrBuilder or any other form as you mentioned. It can be worked out if anyone has a better suggestion.
And about MachineIRBuilder::buildCopy, I feel it is better to retain this very specific instance considering the actual function being called ( the generic MachineIRBuilder::buildInstr) and the operands used which are different from the instances I added.

I believe we need to disambiguate when this one should be used and why.

Admittedly I'm playing the devil's advocate here (I actually like the patch) but I think it is important to flush out the goals and intended usages to be able to better guide future users of this (and the other) API(s).

Cheers,
-Quentin

foad added a subscriber: foad.Feb 16 2023, 9:03 AM
qcolombet accepted this revision.Apr 4 2023, 12:44 AM
This revision is now accepted and ready to land.Apr 4 2023, 12:44 AM
cdevadas abandoned this revision.Jul 18 2023, 4:33 PM

Abandoning this patch as well. It is no longer needed after D150388.