python3Packages.triton: 3.1.0 -> 3.3.1

[GaetanLepage]

Things done

Diff: triton-lang/triton@cf34004...cf34004

cc @SomeoneSerge @Madouura @DerDennisOP

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[GaetanLepage]

Fails with:

FAILED: lib/Analysis/CMakeFiles/TritonAnalysis.dir/AxisInfo.cpp.o
/nix/store/0fsnicvfpf55nkza12cjnad0w84d6ba7-gcc-wrapper-14.2.1.20250322/bin/g++ -DGTEST_HAS_RTTI=0 -I/build/source/python/build/cmake.linux-x86_64-cpython-3.12/lib/Analysis -I/build/source/lib/Analysis -I/build/source/include -I/build/source/. -I/nix/store/gaj5ibzfipyjgll4p65h48956dl28ddq-triton-llvm-19.1.0-rc1/include -I/build/source/python/build/cmake.linux-x86_64-cpython-3.12/include -I/build/source/third_party -I/buil>
In file included from /build/source/include/triton/Analysis/AxisInfo.h:8,
                 from /build/source/lib/Analysis/AxisInfo.cpp:6:
/build/source/include/triton/Analysis/Utility.h: In lambda function:
/build/source/include/triton/Analysis/Utility.h:359:31: error: ‘class mlir::CallOpInterface’ has no member named ‘resolveCallableInTable’; did you mean ‘resolveCallable’?
  359 |         auto *callee = callOp.resolveCallableInTable(&symbolTable);
      |                               ^~~~~~~~~~~~~~~~~~~~~~
      |                               resolveCallable
/build/source/include/triton/Analysis/AxisInfo.h: In lambda function:
/build/source/include/triton/Analysis/AxisInfo.h:185:20: error: ‘class mlir::CallOpInterface’ has no member named ‘resolveCallableInTable’; did you mean ‘resolveCallable’?
  185 |             callOp.resolveCallableInTable(&symbolTable));
      |                    ^~~~~~~~~~~~~~~~~~~~~~
      |                    resolveCallable
/build/source/lib/Analysis/AxisInfo.cpp: At global scope:
/build/source/lib/Analysis/AxisInfo.cpp:199:3: error: conflicting return type specified for ‘virtual mlir::LogicalResult mlir::triton::{anonymous}::AxisInfoAnalysis::visitOperation(mlir::Operation*, llvm::ArrayRef<const mlir::dataflow::Lattice<mlir::triton::AxisInfo>*>, llvm::ArrayRef<mlir::dataflow::Lattice<mlir::triton::AxisInfo>*>)’
  199 |   visitOperation(Operation *op,
      |   ^~~~~~~~~~~~~~
In file included from /build/source/include/triton/Analysis/AxisInfo.h:4:
/nix/store/gaj5ibzfipyjgll4p65h48956dl28ddq-triton-llvm-19.1.0-rc1/include/mlir/Analysis/DataFlow/SparseAnalysis.h:280:16: note: overridden function is ‘void mlir::dataflow::SparseForwardDataFlowAnalysis<StateT>::visitOperation(mlir::Operation*, llvm::ArrayRef<const StateT*>, llvm::ArrayRef<U*>) [with StateT = mlir::dataflow::Lattice<mlir::triton::AxisInfo>]’
  280 |   virtual void visitOperation(Operation *op, ArrayRef<const StateT *> operands,
      |                ^~~~~~~~~~~~~~
/build/source/lib/Analysis/AxisInfo.cpp: In member function ‘virtual void mlir::triton::{anonymous}::AxisInfoAnalysis::setToEntryState(mlir::dataflow::Lattice<mlir::triton::AxisInfo>*)’:
/build/source/lib/Analysis/AxisInfo.cpp:176:66: error: ‘class mlir::dataflow::Lattice<mlir::triton::AxisInfo>’ has no member named ‘getAnchor’
  176 |                      AxisInfo::getPessimisticValueState(lattice->getAnchor())));
      |                                                                  ^~~~~~~~~
/build/source/lib/Analysis/AxisInfo.cpp: In member function ‘void mlir::triton::{anonymous}::AxisInfoAnalysis::visitForOpInductionVar(mlir::scf::ForOp, llvm::ArrayRef<mlir::dataflow::Lattice<mlir::triton::AxisInfo>*>)’:
/build/source/lib/Analysis/AxisInfo.cpp:1104:32: error: ‘getProgramPointAfter’ was not declared in this scope; did you mean ‘getProgramPoint’?
 1104 |   ProgramPoint *programPoint = getProgramPointAfter(op);
      |                                ^~~~~~~~~~~~~~~~~~~~
      |                                getProgramPoint
/build/source/lib/Analysis/AxisInfo.cpp:1106:28: error: cannot convert ‘mlir::ProgramPoint*’ to ‘mlir::ProgramPoint’
 1106 |       getLatticeElementFor(programPoint, op.getLowerBound())->getValue();
      |                            ^~~~~~~~~~~~
      |                            |
      |                            mlir::ProgramPoint*
/nix/store/gaj5ibzfipyjgll4p65h48956dl28ddq-triton-llvm-19.1.0-rc1/include/mlir/Analysis/DataFlow/SparseAnalysis.h:314:51: note:   initializing argument 1 of ‘const StateT* mlir::dataflow::SparseForwardDataFlowAnalysis<StateT>::getLatticeElementFor(mlir::ProgramPoint, mlir::Value) [with StateT = mlir::dataflow::Lattice<mlir::triton::AxisInfo>]’
  314 |   const StateT *getLatticeElementFor(ProgramPoint point, Value value) {
      |                                      ~~~~~~~~~~~~~^~~~~
/build/source/lib/Analysis/AxisInfo.cpp:1108:28: error: cannot convert ‘mlir::ProgramPoint*’ to ‘mlir::ProgramPoint’
 1108 |       getLatticeElementFor(programPoint, op.getStep())->getValue();
      |                            ^~~~~~~~~~~~
      |                            |
      |                            mlir::ProgramPoint*

[stephen-huan]

@GaetanLepage thanks for the draft!

Since my modifications became relatively substantial (and it is awkward to comment on files outside of this PR), I opened a PR based on yours in #419179. Happy to close in favor of yours or vice versa, up to you.

mlir errors are often caused by a mismatch between triton and the llvm version it expects here (replace main with the version, e.g. https://github.com/triton-lang/triton/blob/v3.3.1/cmake/llvm-hash.txt for this version). I've added a comment above the source as a reminder to bump triton-llvm with triton.

The version of triton-llvm can be found here, again, replacing main with the version (here, https://github.com/llvm/llvm-project/blob/a66376b0dc3b2ea8a84fda26faca287980986f78/cmake/Modules/LLVMVersion.cmake). I've updated the outdated comments in triton-llvm to reflect this.

Lastly, the patch 0004-nvidia-allow-static-ptxas-path.patch needs to be updated and the patch 0001-setup.py-introduce-TRITON_OFFLINE_BUILD.patch which you disabled in a comment can be safely removed as it's in upstream already (triton-lang/triton#4414, see e.g. here).

I haven't tested exactly my PR as it is in nixpkgs, but I've tested a variant of it in the context of maipkgs as I need some workarounds to avoid (1) the tests hanging and (2) running out of memory with multiple cores. It's possible I missed something though, so tests appreciated.

[GaetanLepage]

@GaetanLepage thanks for the draft!

Since my modifications became relatively substantial (and it is awkward to comment on files outside of this PR), I opened a PR based on yours in #419179. Happy to close in favor of yours or vice versa, up to you.

mlir errors are often caused by a mismatch between triton and the llvm version it expects here (replace main with the version, e.g. https://github.com/triton-lang/triton/blob/v3.3.1/cmake/llvm-hash.txt for this version). I've added a comment above the source as a reminder to bump triton-llvm with triton.

The version of triton-llvm can be found here, again, replacing main with the version (here, https://github.com/llvm/llvm-project/blob/a66376b0dc3b2ea8a84fda26faca287980986f78/cmake/Modules/LLVMVersion.cmake). I've updated the outdated comments in triton-llvm to reflect this.

Lastly, the patch 0004-nvidia-allow-static-ptxas-path.patch needs to be updated and the patch 0001-setup.py-introduce-TRITON_OFFLINE_BUILD.patch which you disabled in a comment can be safely removed as it's in upstream already (triton-lang/triton#4414, see e.g. here).

I haven't tested exactly my PR as it is in nixpkgs, but I've tested a variant of it in the context of maipkgs as I need some workarounds to avoid (1) the tests hanging and (2) running out of memory with multiple cores. It's possible I missed something though, so tests appreciated.

Thanks a lot for taking up this one!
Let's keep working on your PR. I'll try to do more testing ASAP.