#9329: Restructure ttnn::argmax

[ayerofieiev-tt]

Description

Guiding principles

Keep everything related to a single op at a single place
User documentation and code organization should be aligned
Code organization reflects ownership

Change

Updated ttnn.argmax according to the described structure #9329

See the structure in an interactive form here:
https://github.com/tenstorrent/tt-metal/tree/ay/issue-9329-argmax-ttnn-struct/ttnn/cpp/ttnn/operations/reduction

from

- pybind11
  - operations
    - ...
    - reduction.hpp
    - ...
  - ...
- ttnn
  - op_library 
    - ...
    -  reduction
      - argmax_create_program.cpp
      - reduction_op.cpp
      - reduction_op.hpp
      - kernels
        - reader_argmax_interleave.cpp
  - operations
   - ...
   - reduction.hpp
   - ...

to

- operations
  - reduction
    - reduction_pybind.hpp
    - argmax
      - argmax.hpp
      - argmax_pybind.hpp
      - device
        - argmax_op.hpp
        - argmax_op.cpp
        - argmax_program_factory.hpp
        - kernels
          - reader_argmax_interleaved
    - generic
      - generic_reductions.hpp
      - generic_reductions_pybind.hpp

Checklist

• Post commit CI passes https://github.com/tenstorrent/tt-metal/actions/runs/9425630406

[TT-BrianLiu]

The new structure looks really good!

Code changes:

• ttnn/cpp/ttnn/operations/reduction/argmax/device/argmax_program_factory.hpp has a dependency on ttnn/cpp/ttnn/op_library/reduction/reduction_op.hpp which is removed?
• We should remove ttnn/cpp/pybind11/operations/reduction.hpp since it is no longer used. (Side note: Are we going to have a top level pybind once ttnn/cpp/pybind11 is completely removed?)

And a few questions:

• If we have something like generic, should we also rename the underlying files generic? I find it confusing that there is a generic/reduction_pybind.hpp and a top-level reduction_pybind.hpp. We can also call it generic_reduction and have all files match if just generic is weird. This is important to get right since we have other ops like binary and unary that will have similar patterns.
• We are intentionally calling it pybind and not pybind11?
• Is it intentional that we no longer have cpp files? If we had them, should we also enforce each op owning their own CMakeLists?

[ayerofieiev-tt]

@TT-BrianLiu

ttnn/cpp/ttnn/operations/reduction/argmax/device/argmax_program_factory.hpp has a dependency on ttnn/cpp/ttnn/op_library/reduction/reduction_op.hpp which is removed?

Yes. Thank you for spotting! Cleanup.

We should remove ttnn/cpp/pybind11/operations/reduction.hpp since it is no longer used.

Done! Thanks!

(Side note: Are we going to have a top level pybind once ttnn/cpp/pybind11 is completely removed?)

Yes, hierarchy will migrate naturally as we merge things.

If we have something like generic, should we also rename the underlying files generic? I find it confusing that there is a generic/reduction_pybind.hpp and a top-level reduction_pybind.hpp. We can also call it generic_reduction and have all files match if just generic is weird. This is important to get right since we have other ops like binary and unary that will have similar patterns.

Agreed. Renamed to generic_reductions.hpp and 'generic_reductions_pybind.hpp`.

We are intentionally calling it pybind and not pybind11?

Yes, it is clear that those are python bindings, that should be plenty.

Is it intentional that we no longer have cpp files? If we had them, should we also enforce each op owning their own CMakeLists?

I missed it and it somehow built, but then import ttnn did not work.
For now, added the cpp to the top cmakelist, but

• I really do not like this approach.
• I'd like to avoid file glob
• I would usually prefer a separate local cmake, but in this case creating additional file to store a single line does not seem good.