This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen][NFC] Remove unused virtual function
ClosedPublic

Authored by myhsu on May 28 2021, 9:50 AM.

Details

Summary

Context: https://reviews.llvm.org/D101588

TargetFrameLowering::emitCalleeSavedFrameMoves with 4 arguments is not used anywhere in CodeGen. Thus it shouldn't be exposed as a virtual function. NFC.

Diff Detail

Event Timeline

myhsu created this revision.May 28 2021, 9:50 AM
myhsu requested review of this revision.May 28 2021, 9:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 28 2021, 9:50 AM
dblaikie added inline comments.May 28 2021, 11:25 AM
llvm/lib/Target/M68k/M68kFrameLowering.cpp
659

Is this a change in behavior? Or is the 3 arg version just the 4 arg version with 'true' as the 4th arg?

myhsu marked an inline comment as done.May 28 2021, 11:56 AM
myhsu added inline comments.
llvm/lib/Target/M68k/M68kFrameLowering.cpp
659

This doesn't change any behavior. This function has always been 3 arguments until D101588, in which we added the 4-th argument only to conform with the virtual function prototype we're removing here. But the added 4-th argument has never been used at all in the function body so removing it is safe and doesn't change any behavior.

myhsu marked an inline comment as done.May 28 2021, 3:39 PM
dblaikie added inline comments.May 28 2021, 5:08 PM
llvm/lib/Target/M68k/M68kFrameLowering.cpp
659

Hmm, I'm a bit confused then - so this M68KFrameLowering has a function "emitCalleeSavedFrameMoves" that takes 3 arguments and the base class has one that's a no-op and only takes two arguments & isn't overriden by the M68KFrameLowering backend. Is that right? That seems somewhat problematic - does that mean generic code that's calling the virtual function isn't getting the desired implementation? Or is the 2 argument version really intended to be a no-op for M68KFrameLowering? Despite there being a 3 arg version that does do some work?

Any chance there's a reasonable other name for the function, if it's not related to the virtual one?

The X86 one makes sense to me, for instance - in that the 2 arg virtual one is implemented in terms of the 4 arg (now non-virtual) one. But the M68k one isn't quite making sense to me that there's a 3 arg function with the same name that does work - despite the 2-arg one still being the default implementation that does nothing?

myhsu added inline comments.Jun 1 2021, 8:49 PM
llvm/lib/Target/M68k/M68kFrameLowering.cpp
659

That seems somewhat problematic - does that mean generic code that's calling the virtual function isn't getting the desired implementation? Or is the 2 argument version really intended to be a no-op for M68KFrameLowering? Despite there being a 3 arg version that does do some work?

I agree with this, I'll rename the current emitCalleeSavedFrameMoves into some other name

myhsu updated this revision to Diff 349172.Jun 1 2021, 9:53 PM

Rename M68kFrameLowering::emitCalleeSavedFrameMoves with 3 args into another name to avoid confusion

myhsu marked an inline comment as done.Jun 1 2021, 9:53 PM
dblaikie accepted this revision.Jun 2 2021, 9:21 AM
dblaikie added a subscriber: tmsriram.

Thanks!

(@tmsriram - perhaps you could rename the X86 version of this function too in a separate patch, to avoid overloading a virtual/reduce confusion here? (I think this function was added for BB sections & was initially virtual in the base FrameLowering API - but has now been sunk into the X86 backend/etc)

This revision is now accepted and ready to land.Jun 2 2021, 9:21 AM
This revision was landed with ongoing or failed builds.Jun 2 2021, 1:13 PM
This revision was automatically updated to reflect the committed changes.