Move OpInfo class into new opinfo folder

[peterbell10]

Stack from ghstack (oldest at bottom):

• Move OpInfo subclasses into opinfo.core #82830
• -> Move OpInfo class into new opinfo folder #82540

Ref #82518

Starting small to minimize merge conflicts, this moves the top-level
class definitions and some helper functions into the opinfos folder.
It also brings common_methods_invocations.py to just below 1MB.

[facebook-github-bot]

🔗 Helpful links

• 🧪  See artifacts and rendered test results at hud.pytorch.org/pr/82540
• 📄  Preview Python docs built from this PR
• 📄  Preview C++ docs built from this PR
• ❓Need help or want to give feedback on the CI? Visit our office hours

✅ No Failures (2 Pending)

As of commit 87d83ac (more details on the Dr. CI page):

Expand to see more

---

💚 💚 Looks good so far! There are no failures yet. 💚 💚

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[albanD]

I'll wait for the discussion on the issue to lead to a consensus before working towards merging this right?

[peterbell10]

Personally I think this should be merged ASAP. It brings common_methods_invocations.py under 1MB which is the main problem atm and this change doesn't depend on how we group the op_db definitions into different files.

[albanD]

Ok, the change sounds ok but I would have a couple questions:

• Why opinfoS (with an S)? This folder does not contain a bunch of opinfos, it is (for now only) the core logic.
• Where do we plan to put the splitted OpInfo definitions in this new architecture?

[peterbell10]

Where do we plan to put the splitted OpInfo definitions in this new architecture?

My thinking was that we would (eventually) move all the definitions somewhere inside this opinfos folder. File structure TBD.

Why opinfoS (with an S)?

Assuming all the opinfos are defined in the folder it makes more sense. I don't mind dropping it though.

[albanD]

What about a final structure like?

testing/
  _internal/
    opinfo/
      core.py
      utils.py    
      definitions/
        linalg.py
        fft.py
        nn.py
        ....

• We use utils.py and not helper.py within the codebase in general
• Have a subfolder with the definitions to make greping the definitions only simpler.
• Is the __init__.py actually needed here?

[peterbell10]

We use utils.py and not helper.py within the codebase in general

Sure, I just renamed the existing opinfo_helper.py.

Have a subfolder with the definitions to make greping the definitions only simpler.

Makes sense to me. Though I don't have any strong feelings either way.

Is the __init__.py actually needed here?

AFAIK it's always recommended to include an __init__.py file, even if it's empty. See https://stackoverflow.com/a/48804718/2556706

[albanD]

SGTM!

[albanD]

Not sure when is the best time to land this to avoid land races...

[albanD]

I'm merging this to avoid any merge conflict if we wait too long.

[albanD]

@pytorchbot merge -g

[pytorchmergebot]

@pytorchbot successfully started a merge job. Check the current status here

[github-actions]

Hey @peterbell10.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.