Pass the target machine to the LLVM pass builder #4655
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
giuseros
requested review from
antiagainst,
zhanglx13 and
ptillet
as code owners
antiagainst
pushed a commit
that referenced
this pull request
Sep 8, 2024
#4655 sets the TargetMachine primarily for the AMD backend but we want it to remain nullptr when using LLVM IR level plugins as well. This PR just adds an additional check when adding TargetMachine value.
leshikus
pushed a commit
to intel/intel-xpu-backend-for-triton
that referenced
this pull request
Sep 12, 2024
triton-lang/triton#4655 sets the TargetMachine primarily for the AMD backend but we want it to remain nullptr when using LLVM IR level plugins as well. This PR just adds an additional check when adding TargetMachine value.
bertmaher
pushed a commit
to bertmaher/triton
that referenced
this pull request
Dec 10, 2024
In a recent change to the [LLVM AMD backend](llvm/llvm-project#83131), we moved the `AMDGPUAttributor` pass into the optimization pipeline (as opposed to the codegen pipeline). Since this is a pass specific for `AMD` targets, we want to pass the `TargetMachine` when building the pipeline, i.e., during the call to `optimize_module`. Failure to do so will result in an increase of number of registers used. Also, we spoke with our LLVM backend team, and they advised to always pass the `TargetMachine` when building the LLVM optimization pipeline. This PR is addressing this issue, in the following way: - I added optional parameters to the `optimize_module` funciton (similar to those passed to `translate_to_asm`) - if those params are passed in, then we will create the `TargetMachine` and pass it to the `PassBuilder` - Otherwise the `TargetMachine` will still be `nullptr` (as it was before) Please note that, as it stands now, this change will only effect the AMD backend.
bertmaher
pushed a commit
to bertmaher/triton
that referenced
this pull request
Dec 10, 2024
…g#4669) triton-lang#4655 sets the TargetMachine primarily for the AMD backend but we want it to remain nullptr when using LLVM IR level plugins as well. This PR just adds an additional check when adding TargetMachine value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a recent change to the LLVM AMD backend, we moved the
AMDGPUAttributorpass into the optimization pipeline (as opposed to the codegen pipeline).Since this is a pass specific for
AMDtargets, we want to pass theTargetMachinewhen building the pipeline, i.e., during the call tooptimize_module.Failure to do so will result in an increase of number of registers used. Also, we spoke with our LLVM backend team, and they advised to always pass the
TargetMachinewhen building the LLVM optimization pipeline.This PR is addressing this issue, in the following way:
optimize_modulefunciton (similar to those passed totranslate_to_asm)TargetMachineand pass it to thePassBuilderTargetMachinewill still benullptr(as it was before)Please note that, as it stands now, this change will only effect the AMD backend.