[aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

chenyang78 · 2024-04-01T23:34:21Z

Stack from ghstack (oldest at bottom):

-> [aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

After we codegen a triton kernel in the triton codegen backend,
we cache the generated triton source code in the wrapper to avoid
producing multiple triton kernels with the same content.

In AOTI compilation flow, this caching mechanism imposes a strong requirement
on the codegen that we must generate the same triton source code
for the same schedule node in both python and cpp codegen phases.
Otherwise, we would end up with a mismatch between the kernel name
formed in the cpp codegen and the cuda kernel key produced from
the python codegen. Consequently, we would hit an missing-cuda-kernel
error.

The precomputed symbol replacements saved in V.graph.sizevars
can cause such source-code inconsistency related to the code for indexing
tensors. For example, let's say in the python codegen phase,
we produce "ks2*48" as part of indexing an input for schedule
node A while yielding a replacement pair "ks0 -> ks2*48" in
the precomputed replacements. In the second cpp codegen phase,
we would produce "ks0" for the same indexing code of schedule
node A due to the "ks0 -> ks2*48" replacement pair.

This PR fixed the issue by clearing precomputed_replacements
and inv_precomputed_replacements before cpp wrapper codegen.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @kadeng @muchulee8 @aakhundov @ColinPeppler @amjames @desertfire @chauhang

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. [ghstack-poisoned]

pytorch-bot · 2024-04-01T23:34:25Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/123136

📄 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 the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

✅ You can merge normally! (2 Unrelated Failures)

As of commit a408d2a with merge base 26bf05c ():

UNSTABLE - The following jobs failed but were likely due to flakiness present on trunk and has been marked as unstable:

inductor / rocm6.0-py3.8-inductor / test (inductor, 1, 1, linux.rocm.gpu.2, unstable) (gh)
test/distributed/_composable/fsdp/test_fully_shard_training.py::TestFullyShard1DTrainingCore::test_train_parity_multi_group_eager
rocm / linux-focal-rocm6.0-py3.8 / test (default, 2, 6, linux.rocm.gpu.2, unstable) (gh)
inductor/test_templated_attention.py::TestTemplatedSDPA::test_alibi_causal_float16

This comment was automatically generated by Dr. CI and updates every 15 minutes.

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. ghstack-source-id: 2f73de7900b74d409757edad38270bc82d3dadba Pull Request resolved: #123136

…e cpp wrapper compilation" After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 kadeng muchulee8 aakhundov ColinPeppler amjames desertfire chauhang [ghstack-poisoned]

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. ghstack-source-id: fb3f5b9847681f3b289e5523f2c4536330c36bc4 Pull Request resolved: #123136

chenyang78 · 2024-04-02T06:11:39Z

@pytorchbot merge

pytorchmergebot · 2024-04-02T06:14:34Z

Merge failed

Reason: This PR needs a release notes: label
If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Details for Dev Infra team

Raised by workflow job

chenyang78 · 2024-04-02T06:17:53Z

@pytorchbot merge

pytorchmergebot · 2024-04-02T06:19:35Z

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

albanD · 2024-04-02T14:15:17Z

@pytorchbot revert -m "broke ROCm CI" -c "nosignal"

pytorchmergebot · 2024-04-02T14:16:55Z

@pytorchbot successfully started a revert job. Check the current status here.
Questions? Feedback? Please reach out to the PyTorch DevX Team

pytorchmergebot · 2024-04-02T14:17:08Z

@chenyang78 your PR has been successfully reverted.

…pp wrapper compilation (#123136)" This reverts commit 7eadb15. Reverted #123136 on behalf of https://github.com/albanD due to broke ROCm CI ([comment](#123136 (comment)))

jithunnair-amd · 2024-04-03T03:31:34Z

@chenyang78 I'm not sure why this PR was filed; the original PR was reopened and I commented on it suggesting how to avoid the ROCm CI breakages: #122882 (comment). Please update the original PR and reland it.

chenyang78 · 2024-04-04T18:45:58Z

@chenyang78 I'm not sure why this PR was filed; the original PR was reopened and I commented on it suggesting how to avoid the ROCm CI breakages: #122882 (comment). Please update the original PR and reland it.

@jithunnair-amd I am really sorry that I missed your comment! I made the suggested changes in this PR and will close the original one. BTW, the original PR was reverted because it caused some internal issue.

…e cpp wrapper compilation" After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 kadeng muchulee8 aakhundov ColinPeppler amjames desertfire chauhang [ghstack-poisoned]

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. ghstack-source-id: a4d150f0ed7c763b88d9900cca8dd39e24337bec Pull Request resolved: #123136

…e cpp wrapper compilation" After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 kadeng muchulee8 aakhundov ColinPeppler amjames desertfire chauhang [ghstack-poisoned]

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. ghstack-source-id: ffac0544644e8b4d690c5d5eb4046f4d70fd9466 Pull Request resolved: #123136

chenyang78 · 2024-04-05T02:25:44Z

@jithunnair-amd Hmm, seems the ROCM CI is currently broken. Just want to check if you are aware of this. I see the following failure, (which is unlikely related to my changes in the PR)

024-04-04T20:54:07.8252520Z FAILED: caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/torch_hip_generated_SparseSemiStructuredTile.hip.o /var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/torch_hip_generated_SparseSemiStructuredTile.hip.o 
2024-04-04T20:54:07.8259039Z cd /var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip && /opt/conda/envs/py_3.8/bin/cmake -E make_directory /var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/. && /opt/conda/envs/py_3.8/bin/cmake -D verbose:BOOL=OFF -D build_configuration:STRING=RELEASE -D generated_file:STRING=/var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/./torch_hip_generated_SparseSemiStructuredTile.hip.o -P /var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/torch_hip_generated_SparseSemiStructuredTile.hip.o.cmake
2024-04-04T20:54:07.8264043Z In file included from /var/lib/jenkins/workspace/aten/src/ATen/native/sparse/hip/SparseSemiStructuredTile.hip:6:
2024-04-04T20:54:07.8265380Z In file included from /var/lib/jenkins/workspace/aten/src/ATen/native/sparse/hip/ComputeSparseTile.h:4:
2024-04-04T20:54:07.8266695Z In file included from /var/lib/jenkins/workspace/aten/src/ATen/native/sparse/hip/SparseSemiStructuredPack.h:4:
2024-04-04T20:54:07.8268355Z /var/lib/jenkins/workspace/aten/src/ATen/native/sparse/hip/StaticSort.h:3:10: fatal error: 'cutlass/cutlass.h' file not found
2024-04-04T20:54:07.8269378Z #include <cutlass/cutlass.h>
2024-04-04T20:54:07.8269722Z          ^~~~~~~~~~~~~~~~~~~
2024-04-04T20:54:07.8270145Z 1 error generated when compiling for host.
2024-04-04T20:54:07.8270845Z CMake Error at torch_hip_generated_SparseSemiStructuredTile.hip.o.cmake:146 (message):
2024-04-04T20:54:07.8271521Z   Error generating
2024-04-04T20:54:07.8272598Z   /var/lib/jenkins/workspace/build/caffe2/CMakeFiles/torch_hip.dir/__/aten/src/ATen/native/sparse/hip/./torch_hip_generated_SparseSemiStructuredTile.hip.o

…e cpp wrapper compilation" After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 kadeng muchulee8 aakhundov ColinPeppler amjames desertfire chauhang [ghstack-poisoned]

…er compilation After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. ghstack-source-id: cb24eb5051469f06e7c2450866de8c8d8d27372a Pull Request resolved: #123136

chenyang78 · 2024-04-08T16:49:43Z

@pytorchbot merge

pytorchmergebot · 2024-04-08T16:51:30Z

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

…er compilation (pytorch#123136) After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. Pull Request resolved: pytorch#123136 Approved by: https://github.com/desertfire

…pp wrapper compilation (pytorch#123136)" This reverts commit 7eadb15. Reverted pytorch#123136 on behalf of https://github.com/albanD due to broke ROCm CI ([comment](pytorch#123136 (comment)))

…er compilation (pytorch#123136) After we codegen a triton kernel in the triton codegen backend, we cache the generated triton source code in the wrapper to avoid producing multiple triton kernels with the same content. In AOTI compilation flow, this caching mechanism imposes a strong requirement on the codegen that we must generate the same triton source code for the same schedule node in both python and cpp codegen phases. Otherwise, we would end up with a mismatch between the kernel name formed in the cpp codegen and the cuda kernel key produced from the python codegen. Consequently, we would hit an missing-cuda-kernel error. The precomputed symbol replacements saved in V.graph.sizevars can cause such source-code inconsistency related to the code for indexing tensors. For example, let's say in the python codegen phase, we produce "ks2\*48" as part of indexing an input for schedule node A while yielding a replacement pair "ks0 -> ks2\*48" in the precomputed replacements. In the second cpp codegen phase, we would produce "ks0" for the same indexing code of schedule node A due to the "ks0 -> ks2*48" replacement pair. This PR fixed the issue by clearing precomputed_replacements and inv_precomputed_replacements before cpp wrapper codegen. Pull Request resolved: pytorch#123136 Approved by: https://github.com/desertfire

pytorch-bot bot added ciflow/inductor module: inductor labels Apr 1, 2024

chenyang78 requested a review from desertfire April 1, 2024 23:34

desertfire approved these changes Apr 2, 2024

View reviewed changes

pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Apr 2, 2024

pytorchmergebot added the merging label Apr 2, 2024

pytorchmergebot removed the merging label Apr 2, 2024

chenyang78 added the topic: not user facing topic category label Apr 2, 2024

pytorchmergebot added the merging label Apr 2, 2024

pytorchmergebot added the Merged label Apr 2, 2024

pytorchmergebot closed this in 7eadb15 Apr 2, 2024

pytorchmergebot removed the merging label Apr 2, 2024

pytorchmergebot added the Reverted label Apr 2, 2024

pytorchmergebot reopened this Apr 2, 2024

chenyang78 added the ciflow/rocm label Apr 4, 2024

pytorchmergebot added the merging label Apr 8, 2024

pytorchmergebot closed this in e4e5449 Apr 8, 2024

pytorchmergebot removed the merging label Apr 8, 2024

chenyang78 mentioned this pull request Apr 10, 2024

[aoti] clear precomputed symbol replacements before cpp wrapper compilation #122882

Closed

github-actions bot deleted the gh/chenyang78/20/head branch May 9, 2024 02:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

[aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

chenyang78 commented Apr 1, 2024 •

edited by pytorch-bot bot

Loading

pytorch-bot bot commented Apr 1, 2024 •

edited

Loading

chenyang78 commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

chenyang78 commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

albanD commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

jithunnair-amd commented Apr 3, 2024

chenyang78 commented Apr 4, 2024

chenyang78 commented Apr 5, 2024

chenyang78 commented Apr 8, 2024

pytorchmergebot commented Apr 8, 2024

[aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

[aoti][reland] clear precomputed symbol replacements before cpp wrapper compilation #123136

Conversation

chenyang78 commented Apr 1, 2024 • edited by pytorch-bot bot Loading

pytorch-bot bot commented Apr 1, 2024 • edited Loading

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/123136

✅ You can merge normally! (2 Unrelated Failures)

chenyang78 commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

Merge failed

chenyang78 commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

Merge started

albanD commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

pytorchmergebot commented Apr 2, 2024

jithunnair-amd commented Apr 3, 2024

chenyang78 commented Apr 4, 2024

chenyang78 commented Apr 5, 2024

chenyang78 commented Apr 8, 2024

pytorchmergebot commented Apr 8, 2024

Merge started

chenyang78 commented Apr 1, 2024 •

edited by pytorch-bot bot

Loading

pytorch-bot bot commented Apr 1, 2024 •

edited

Loading