This is an archive of the discontinued LLVM Phabricator instance.

[DFAPacketizer] Move DefaultVLIWScheduler class declaration to header file
ClosedPublic

Authored by DarshanRamakant on Dec 9 2022, 9:43 PM.

Details

Summary

This change moves "DefaultVLIWScheduler" class declaration from
DFAPacketizer.cpp to DFAPacketizer.h.
This is needed because there is a protected class member of
type "DefaultVLIWScheduler*" in "VLIWPacketizerList" class.
The derived classes cannot use this memeber unless declaration
is available to it. More specifically :

// Without this change

class HexagonPacketizerList : public VLIWPacketizerList {
  public :
	HexagonPacketizerList() {
	// Below line will cause incomplete class error since
	// declaration was not available through header.
	VLIWScheduler->schedule();
  }
}

Diff Detail

Event Timeline

DarshanRamakant created this revision.Dec 9 2022, 9:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2022, 9:43 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
DarshanRamakant requested review of this revision.Dec 9 2022, 9:43 PM
DarshanRamakant edited the summary of this revision. (Show Details)Dec 9 2022, 9:44 PM
kazu removed a reviewer: kazu.Dec 9 2022, 9:52 PM
Nicola resigned from this revision.Dec 10 2022, 4:07 AM
dexonsmith resigned from this revision.Dec 10 2022, 9:38 AM

I don't know much about this code; resigning as reviewer. But I took a quick look. I wonder if this the right fix, or whether VLIWPacketizerList::VLIWScheduler's type should be ScheduleDAGInstrs, and downcast when necessary on use, allowing DefaultVLIWScheduler to stay private. (Up to others to sort out!)

I don't know much about this code; resigning as reviewer. But I took a quick look. I wonder if this the right fix, or whether VLIWPacketizerList::VLIWScheduler's type should be ScheduleDAGInstrs, and downcast when necessary on use, allowing DefaultVLIWScheduler to stay private. (Up to others to sort out!)

Thanks @dexonsmith for the suggestion. But I think even if we want to downcast ( dynamic_cast) the declaration should be available to the derived class, which is not the case in the current implementation.

I don't know much about this code; resigning as reviewer. But I took a quick look. I wonder if this the right fix, or whether VLIWPacketizerList::VLIWScheduler's type should be ScheduleDAGInstrs, and downcast when necessary on use, allowing DefaultVLIWScheduler to stay private. (Up to others to sort out!)

Thanks @dexonsmith for the suggestion. But I think even if we want to downcast ( dynamic_cast) the declaration should be available to the derived class, which is not the case in the current implementation.

Not sure I'm following, maybe I've misread something, but it seems like:

  • Your example (HexagonPacketizerList) could just call ScheduleDAGInstrs::schedule(), which is a public method. No need to downcast.
  • Within llvm/lib/CodeGen/DFAPacketizer.cpp, code that needs to call addMutation() might need to downcast. This would be a static_cast though, since the implementation knows the type. (Note: LLVM builds without RTTI, so dynamic_cast never works. If you don't know what type to downcast to, you need to save type info explicitly somehow in the base class.)

I don't know much about this code; resigning as reviewer. But I took a quick look. I wonder if this the right fix, or whether VLIWPacketizerList::VLIWScheduler's type should be ScheduleDAGInstrs, and downcast when necessary on use, allowing DefaultVLIWScheduler to stay private. (Up to others to sort out!)

Thanks @dexonsmith for the suggestion. But I think even if we want to downcast ( dynamic_cast) the declaration should be available to the derived class, which is not the case in the current implementation.

Not sure I'm following, maybe I've misread something, but it seems like:

  • Your example (HexagonPacketizerList) could just call ScheduleDAGInstrs::schedule(), which is a public method. No need to downcast.
  • Within llvm/lib/CodeGen/DFAPacketizer.cpp, code that needs to call addMutation() might need to downcast. This would be a static_cast though, since the implementation knows the type. (Note: LLVM builds without RTTI, so dynamic_cast never works. If you don't know what type to downcast to, you need to save type info explicitly somehow in the base class.)

My idea was to make "DefaultVLIWScheduler" class type available to derived classes of "VLIWPacketizerList" so that even "addMutatation()" can be used in derived classes. But I also ok with changing the member type to base class. Waiting for other reviewers comments.

Gentle reminder to review the change !

Hi All,

I have been waiting for a review for this change for 3 weeks. Please review
the code and allow me to merge the changes if the code looks good.

Thanks,
Darshan Bhat

kparzysz added a comment.EditedJan 6 2023, 10:57 AM

The DefaultVLIWScheduler class is really a thin wrapper on top of ScheduleDAGInstrs that holds/applies graph mutations. It doesn't really do anything useful on its own, and there isn't much there that you can customize. I'm not sure why you'd want to make it available, could you explain your use case?

DarshanRamakant added inline comments.Jan 6 2023, 9:55 PM
llvm/include/llvm/CodeGen/DFAPacketizer.h
143

@kparzysz , this type will become incomplete class type for the child class of VLIWPacketizerList unless declaration of "DefaultVLIWScheduler" is moved to this header.
Since this member is a protected member, I assume the design intention was to make it available to child class.

My usecase was to access this member and call "schedule()" method of it.

This patch just moves the declaration from cpp file to header file.

Please let me know how to submit this change if there are no other comments / concerns.

kparzysz accepted this revision.Jan 13 2023, 10:42 AM

I'm not sure how it helps, but this isn't a huge deal anyways.

This revision is now accepted and ready to land.Jan 13 2023, 10:42 AM

I'm not sure how it helps, but this isn't a huge deal anyways.

Thanks @kparzysz. I dont have push rights (not sure how to get it) , can you please push this change on behalf of me ?