[inductor] Enable floor_div indexing to work under ABI-compat mode #113276

int3 · 2023-11-08T17:28:59Z

Stack from ghstack (oldest at bottom):

-> [inductor] Enable floor_div indexing to work under ABI-compat mode #113276

Previously, floor_div operations were defined in
ATen/native/BinaryOps.h. Since this header was not included under
ABI-compat mode, trying to use those indexing operations would result in
compilation errors.

Technically, it is safe to use aten::native::floor_div_* functions in
ABI-compat mode as they are header-only; we could simply include
BinaryOps.h. However, there are other declarations in BinaryOps.h that
are not binary-compatible, so this is not ideal. Thus, I have moved those
functions into a separate file, and put them under c10/util, since they
don't really have tensor-specific logic.

c10 functions are not all header-only, so this still isn't ideal, but
this still seems like an improvement. Moreover, cpp_prefix.h -- used
when compiling cpp kernels -- already includes c10 header files, so
ABI-compatibility already depends on maintaining some c10 functions as
header-only.

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @voznesenskym @penguinwu @EikanWang @Guobing-Chen @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler

We need these in order to compile indexing expressions. [ghstack-poisoned]

pytorch-bot · 2023-11-08T17:29:02Z

🔗 Helpful Links

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

📄 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.

✅ No Failures

As of commit ade1029 with merge base 4f2b288 ():
💚 Looks good so far! There are no failures yet. 💚

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

int3 · 2023-11-08T17:32:55Z

torch/csrc/inductor/aoti_torch/shim_common.cpp


 } // namespace

+int64_t aoti_torch_div_floor_int64(int64_t a, int64_t b) {


it appears we only use div_floor_integer<int64_t> when emitting indexing expressions, so I only created this particular instantiation (since C doesn't support overloading)

I think I was doing the same thing for div_floor_integer at some point, but realized we need a way to capture exception here, like divide-by-zero. So making the API similar to others here by using AOTI_TORCH_CONVERT_EXCEPTION_TO_ERROR_CODE seems inevitable, unless @ezyang has a better idea.

@swolchok if you're doing a CPU model and there's some code where we do an integer divide, which potentially may have a zero denominator. What would you prefer the AOTInductor DSO behavior to be in this case?

I don't understand -- div_floor_integer doesn't check for divide by zero.

I also want to clear up what is supposed to happen -- integer division by zero has undefined behavior (https://en.cppreference.com/w/c/language/operator_arithmetic#Division). Therefore: It is not guaranteed to crash the process. it is very unlikely to raise a C++ exception. C++ authors must guarantee that their code does not perform integer division by zero.

supposing that div_floor_integer did check for divide by zero, I would prefer that it was compiled into the DSO, not going through an aoti_torch shim, because those are relatively expensive and it is a small function.

in particular we could simply emit a zero check for the denominator inline and throw an exception, which would be translated into an error code at the boundary and then back into an exception on the other side

I guess regardless of whether it does check or not, it's better to have it compiled into the DSO and/or inlined? Let me look into that...

compiled into the DSO and/or inlined?

can't inline across a DSO boundary, gotta compile into the DSO

Yeah I didn't really phrase things correctly... should not have said "or". I just meant that if we compile the div_floor_* functions into the DSO (I assume that means model.so), then they could possibly be inlined into their callers.

int3 · 2023-11-08T17:33:43Z

torch/csrc/inductor/aoti_torch/shim_common.cpp

 #include <cstdio>
 #include <iostream>
 #include <memory>
+#include <ATen/native/BinaryOps.h>


not sure if this include is OK, or if I should make it part of AT_PER_OPERATOR_HEADERS?

…ons" We need these in order to compile indexing expressions. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]

chenyang78

LGTM. Thanks!

test/inductor/test_indexing.py

…ons" We need these in order to compile indexing expressions. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]

We need these in order to compile indexing expressions. ghstack-source-id: d03eccc Pull Request resolved: #113276

desertfire · 2023-11-08T18:51:36Z

torch/csrc/inductor/aoti_torch/shim_common.cpp


 } // namespace

+int64_t aoti_torch_div_floor_int64(int64_t a, int64_t b) {


I think I was doing the same thing for div_floor_integer at some point, but realized we need a way to capture exception here, like divide-by-zero. So making the API similar to others here by using AOTI_TORCH_CONVERT_EXCEPTION_TO_ERROR_CODE seems inevitable, unless @ezyang has a better idea.

…ons" We need these in order to compile indexing expressions. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]

We need these in order to compile indexing expressions. ghstack-source-id: e3cd099 Pull Request resolved: #113276

These functions are needed for computing indexing expressions. We were previously calling into `aten::native::div_floor_{integer,floating}` when compiling the cpp wrapper code in non-ABI-compatible mode. However, these functions were not available when compiling under ABI-compatible mode as we did not include ATen/native/BinaryOps.h. It is technically safe to call those functions in ABI-compatible mode as they are header-only, but I didn't want to include BinaryOps.h into the cpp wrapper file because it exposes other potentially non-ABI-stable declarations. As such, I have created a new torch/csrc/inductor/math.h file that contains versions of div_floor_* that are clearly uncoupled from libc10 and libtorch. We only need to care about int64_t and double types when computing indexing expressions, so I have only defined div_floor_{int64_, double}. This makes it easy to decouple from c10 code. I also noticed that when compiling the cpp kernels, we include BinaryOps.h directly. I have swapped that out for the new math.h to better enforce the ABI-compatible interface. [ghstack-poisoned]

These functions are needed for computing indexing expressions. We were previously calling into `aten::native::div_floor_{integer,floating}` when compiling the cpp wrapper code in non-ABI-compatible mode. However, these functions were not available when compiling under ABI-compatible mode as we did not include ATen/native/BinaryOps.h. It is technically safe to call those functions in ABI-compatible mode as they are header-only, but I didn't want to include BinaryOps.h into the cpp wrapper file because it exposes other potentially non-ABI-stable declarations. As such, I have created a new torch/csrc/inductor/math.h file that contains versions of div_floor_* that are clearly uncoupled from libc10 and libtorch. We only need to care about int64_t and double types when computing indexing expressions, so I have only defined div_floor_{int64_, double}. This makes it easy to decouple from c10 code. I also noticed that when compiling the cpp kernels, we include BinaryOps.h directly. I have swapped that out for the new math.h to better enforce the ABI-compatible interface. ghstack-source-id: 3fbffa6 Pull Request resolved: #113276

These functions are needed for computing indexing expressions. We were previously calling into `aten::native::div_floor_{integer,floating}` when compiling the cpp wrapper code in non-ABI-compatible mode. However, these functions were not available when compiling under ABI-compatible mode as we did not include ATen/native/BinaryOps.h. It is technically safe to call those functions in ABI-compatible mode as they are header-only, but I didn't want to include BinaryOps.h into the cpp wrapper file because it exposes other potentially non-ABI-stable declarations. As such, I have created a new torch/csrc/inductor/math.h file that contains versions of div_floor_* that are clearly uncoupled from libc10 and libtorch. We only need to care about int64_t and double types when computing indexing expressions, so I have only defined div_floor_{int64_, double}. This makes it easy to decouple from c10 code. I also noticed that when compiling the cpp kernels, we include BinaryOps.h directly. I have swapped that out for the new math.h to better enforce the ABI-compatible interface. [ghstack-poisoned]

…pat mode" Previously, floor_div operations were defined in ATen/native/BinaryOps.h. Since this header was not included under ABI-compat mode, trying to use those indexing operations would result in compilation errors. Technically, it is safe to use aten::native::floor_div_* functions in ABI-compat mode as they are header-only; we could simply include BinaryOps.h. However, there are other declarations in BinaryOps.h that are not binary-compatible, so this is not ideal. Thus, I have moved those functions into a separate file, and put them under c10/util, since they don't really have tensor-specific logic. c10 functions are not all header-only, so this still isn't ideal, but this still seems like an improvement. Moreover, cpp_prefix.h -- used when compiling cpp kernels -- already includes c10 header files, so ABI-compatibility already depends on maintaining some c10 functions as header-only. [ghstack-poisoned]

int3 · 2023-11-10T02:23:14Z

Alternative approach (with rationale in commit mesage): 3d68d92

I think the current approach is cleaner though.

ezyang · 2023-11-10T15:32:21Z

torch/csrc/inductor/math.h

+#include <cmath>
+#include "c10/macros/Macros.h"
+
+// Functions in this file should be header-only as it is used in ABI-compatible mode.


I don't understand. Is this OK to run from the DSO? Why does it include Macros.h then?

Macros.h doesn't include anything that links to external C++ code, so it's safe

Your statement is true, but it also felt like a slippery slope to me. People who touch those recursively included heads won't necessarily know the ABI constraint of AOTI. Say someone decides to split a header into .h and .cpp, and then it will break our assumption here.

With that being said, I am ok with the current approach if you can also update the linker flags for the abi_compatible mode, e.g. https://github.com/pytorch/pytorch/blob/cb233dada43f016c8fa58979838939c1adda416b/torch/_inductor/codecache.py#L1301C24-L1301C24. Then if the aforementioned change happens, at least we should be able to catch it with our abi_compatible test cases.

Hmm, on a second thought, my suggestion may not be trivial to implement, because the C shim layout does live in libtorch and we need to link against that.

Your statement is true, but it also felt like a slippery slope to me.

Yes, I agree that the situation is not ideal. That said I don't think I am actually making the situation that much worse, because cpp_prefix.h already includes a bunch of c10 and aten headers directly (see updated message at the top of the PR.)

With that being said, I am ok with the current approach if you can also update the linker flags for the abi_compatible mode

It looks like we already avoid linking against c10 when building in fbcode, so I think we're good?

pytorch/torch/_inductor/codecache.py

Lines 1398 to 1399 in cb233da

if not config.is_fbcode():

libs += ["c10"]

I guess it would be better if we checked for abi_compatible instead of is_fbcode, but it seems they are being used interchangeably throughout the codebase...

(Side note: we are commenting on the "make an alternative implementation of div_floor_* functions" approach, which is not the latest version of this PR; the latest version just relocates the existing div_floor_* functions from ATen to c10. Either way, the non-linking of c10 makes this safe.)

pp_prefix.h already includes a bunch of c10 and aten headers directly

This should be fixed.

I guess it would be better if we checked for abi_compatible instead of is_fbcode, but it seems they are being used interchangeably throughout the codebase...

The long-term goal is to only keep the abi-compatible mode for OSS as well. In this case, please change it to check abi_compatible.

…pat mode" Previously, floor_div operations were defined in ATen/native/BinaryOps.h. Since this header was not included under ABI-compat mode, trying to use those indexing operations would result in compilation errors. Technically, it is safe to use aten::native::floor_div_* functions in ABI-compat mode as they are header-only; we could simply include BinaryOps.h. However, there are other declarations in BinaryOps.h that are not binary-compatible, so this is not ideal. Thus, I have moved those functions into a separate file, and put them under c10/util, since they don't really have tensor-specific logic. c10 functions are not all header-only, so this still isn't ideal, but this still seems like an improvement. Moreover, cpp_prefix.h -- used when compiling cpp kernels -- already includes c10 header files, so ABI-compatibility already depends on maintaining some c10 functions as header-only. cc jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 voznesenskym penguinwu EikanWang Guobing-Chen zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]

int3 · 2023-11-10T23:44:08Z

@pytorchbot merge

pytorchmergebot · 2023-11-10T23:46:12Z

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

…pat mode" Previously, floor_div operations were defined in ATen/native/BinaryOps.h. Since this header was not included under ABI-compat mode, trying to use those indexing operations would result in compilation errors. Technically, it is safe to use aten::native::floor_div_* functions in ABI-compat mode as they are header-only; we could simply include BinaryOps.h. However, there are other declarations in BinaryOps.h that are not binary-compatible, so this is not ideal. Thus, I have moved those functions into a separate file, and put them under c10/util, since they don't really have tensor-specific logic. c10 functions are not all header-only, so this still isn't ideal, but this still seems like an improvement. Moreover, cpp_prefix.h -- used when compiling cpp kernels -- already includes c10 header files, so ABI-compatibility already depends on maintaining some c10 functions as header-only. cc jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 voznesenskym penguinwu EikanWang Guobing-Chen zhuhaozhe blzheng wenzhe-nrv jiayisunx peterbell10 ipiszy yf225 chenyang78 kadeng muchulee8 aakhundov ColinPeppler [ghstack-poisoned]

Previously, floor_div operations were defined in ATen/native/BinaryOps.h. Since this header was not included under ABI-compat mode, trying to use those indexing operations would result in compilation errors. Technically, it is safe to use aten::native::floor_div_* functions in ABI-compat mode as they are header-only; we could simply include BinaryOps.h. However, there are other declarations in BinaryOps.h that are not binary-compatible, so this is not ideal. Thus, I have moved those functions into a separate file, and put them under c10/util, since they don't really have tensor-specific logic. c10 functions are not all header-only, so this still isn't ideal, but this still seems like an improvement. Moreover, cpp_prefix.h -- used when compiling cpp kernels -- already includes c10 header files, so ABI-compatibility already depends on maintaining some c10 functions as header-only. ghstack-source-id: 2fe8715 Pull Request resolved: #113276

int3 · 2023-11-10T23:49:31Z

@pytorchbot merge

pytorchmergebot · 2023-11-10T23:51:20Z

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

…ytorch#113276) Previously, floor_div operations were defined in ATen/native/BinaryOps.h. Since this header was not included under ABI-compat mode, trying to use those indexing operations would result in compilation errors. Technically, it is safe to use aten::native::floor_div_* functions in ABI-compat mode as they are header-only; we could simply include BinaryOps.h. However, there are other declarations in BinaryOps.h that are not binary-compatible, so this is not ideal. Thus, I have moved those functions into a separate file, and put them under c10/util, since they don't really have tensor-specific logic. c10 functions are not all header-only, so this still isn't ideal, but this still seems like an improvement. Moreover, cpp_prefix.h -- used when compiling cpp kernels -- already includes c10 header files, so ABI-compatibility already depends on maintaining some c10 functions as header-only. Pull Request resolved: pytorch#113276 Approved by: https://github.com/chenyang78, https://github.com/desertfire

vfdev-5 · 2023-12-12T08:55:11Z

Hey @int3, I think there could be an error coming from this PR. Here is a repro code and the error message:

import torch


def func(x, a):
    n = (a * 1.0) // 8.0
    y = x + n
    return y

cfunc = torch.compile(func, dynamic=True, fullgraph=True)

device = "cpu"
x = torch.tensor(0, dtype=torch.float32, device=device)
a = 12

out = cfunc(x, a)
expected = func(x, a)
torch.testing.assert_close(out, expected)

and

torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
CppCompileError: C++ compile error

Command:
g++ /tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.cpp -shared -fPIC -Wall -std=c++17 -Wno-unused-variable -Wno-unknown-pragmas -D_GLIBCXX_USE_CXX11_ABI=1 -I/pytorch/torch/include -I/pytorch/torch/include/torch/csrc/api/include -I/pytorch/torch/
include/TH -I/pytorch/torch/include/THC -I/usr/include/python3.8 -L/pytorch/torch/lib -L/usr/lib -L/pytorch/torch/lib -ltorch -ltorch_cpu -lgomp -ltorch_python -lc10 -mavx2 -mfma -DCPU_CAPABILITY_AVX2 -O3 -DNDEBUG -ffast-math -fno-finite-math-only -fno-unsafe-math-optimizations
 -march=native -fopenmp -D C10_USING_CUSTOM_GENERATED_MACROS -o /tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.so

Output:
In file included from /tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.cpp:2:
/tmp/torchinductor_root/26/c26eqbkuxvn72gf7p2xujmqjcwf4bo6lxmp6rwborxnf4gldnimh.h: In function ‘at::vec::CPU_CAPABILITY::Vectorized<float> to_float_mask(int)’:
/tmp/torchinductor_root/26/c26eqbkuxvn72gf7p2xujmqjcwf4bo6lxmp6rwborxnf4gldnimh.h:407:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  407 |   *(uint32_t*)&mask = src ? 0xFFFFFFFF : 0;
      |    ^~~~~~~~~~~~~~~~
In file included from /tmp/torchinductor_root/26/c26eqbkuxvn72gf7p2xujmqjcwf4bo6lxmp6rwborxnf4gldnimh.h:16,
                 from /tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.cpp:2:
/pytorch/torch/include/c10/util/generic_math.h: In instantiation of ‘scalar_t c10::div_floor_floating(scalar_t, scalar_t) [with scalar_t = double]’:
/tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.cpp:9:147:   required from here
/pytorch/torch/include/c10/util/generic_math.h:43:31: error: ‘compat_copysign’ was not declared in this scope
   43 |     floordiv = compat_copysign(scalar_t(0), a / b);
      |                ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~

Set TORCH_LOGS="+dynamo" and TORCHDYNAMO_VERBOSE=1 for more information

You can suppress this exception and fall back to eager by setting:
    import torch._dynamo
    torch._dynamo.config.suppress_errors = True

With cat /tmp/torchinductor_root/cn/ccniuvr7xihkubwhdhaaxiiklktdhdbkijsrbb4jkchgiscpeqxn.cpp:

#include "/tmp/torchinductor_root/26/c26eqbkuxvn72gf7p2xujmqjcwf4bo6lxmp6rwborxnf4gldnimh.h"
extern "C" void kernel(const float* in_ptr0,
                       float* out_ptr0,
                       const long ks0)
{
    {
        auto tmp0 = in_ptr0[static_cast<long>(0L)];
        auto tmp1 = c10::convert<float>(c10::div_floor_floating(static_cast<double>((1.00000000000000*ks0)), static_cast<double>(8.00000000000000)));
        auto tmp2 = decltype(tmp0)(tmp0 + tmp1);
        out_ptr0[static_cast<long>(0L)] = tmp2;
    }
}

Introduced by #113276. I've added a test to catch future regressions. [ghstack-poisoned]

Introduced by #113276. I've added a test to catch future regressions. ghstack-source-id: ef8cda1 Pull Request resolved: #115647

Introduced by #113276. I've added a test to catch future regressions. ghstack-source-id: 90f017e Pull Request resolved: #115647

Introduced by #113276. I've added a test to catch future regressions. [ghstack-poisoned]

Introduced by #113276. I've added a test to catch future regressions. Pull Request resolved: #115647 Approved by: https://github.com/desertfire, https://github.com/vfdev-5

Introduced by pytorch#113276. I've added a test to catch future regressions. Pull Request resolved: pytorch#115647 Approved by: https://github.com/desertfire, https://github.com/vfdev-5

[inductor] Add abi-compatible shims for div_floor_* functions

95eb7f2

We need these in order to compile indexing expressions. [ghstack-poisoned]

int3 mentioned this pull request Nov 8, 2023

Support fp8 in AOTInductor + support optional<> in C ABI #112527

Closed

github-actions bot added module: inductor ciflow/inductor labels Nov 8, 2023

int3 commented Nov 8, 2023

View reviewed changes

int3 requested review from chenyang78 and desertfire November 8, 2023 17:33

chenyang78 approved these changes Nov 8, 2023

View reviewed changes

test/inductor/test_indexing.py Show resolved Hide resolved

int3 added a commit that referenced this pull request Nov 8, 2023

[inductor] Add abi-compatible shims for div_floor_* functions

109ff7d

We need these in order to compile indexing expressions. ghstack-source-id: d03eccc Pull Request resolved: #113276

desertfire requested changes Nov 8, 2023

View reviewed changes

int3 added a commit that referenced this pull request Nov 9, 2023

[inductor] Add abi-compatible shims for div_floor_* functions

720906e

We need these in order to compile indexing expressions. ghstack-source-id: e3cd099 Pull Request resolved: #113276

desertfire mentioned this pull request Nov 9, 2023

[AOTI] Use expr_printer to print sympy expr #113317

Closed

int3 changed the title ~~[inductor] Add abi-compatible shims for div_floor_* functions~~ [inductor] Add torch::inductor::div_floor_{int64, double} Nov 10, 2023

int3 changed the title ~~[inductor] Add torch::inductor::div_floor_{int64, double}~~ [inductor] Enable floor_div indexing to work under ABI-compat mode Nov 10, 2023

github-actions bot added the module: cpu CPU specific problem (e.g., perf, algorithm) label Nov 10, 2023

ezyang reviewed Nov 10, 2023

View reviewed changes

pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Nov 10, 2023

pytorchmergebot added the merging label Nov 10, 2023

pytorchmergebot removed the merging label Nov 10, 2023

int3 added the release notes: inductor label Nov 10, 2023

pytorchmergebot added the merging label Nov 10, 2023

pytorchmergebot added Merged and removed merging labels Nov 11, 2023

pytorchmergebot closed this in 5e03af8 Nov 11, 2023

facebook-github-bot deleted the gh/int3/69/head branch November 14, 2023 15:28

int3 mentioned this pull request Dec 12, 2023

Fix c10::div_floor_floating compile error #115647

Closed

int3 added a commit that referenced this pull request Dec 12, 2023

Fix c10::div_floor_floating compile error

7283432

Introduced by #113276. I've added a test to catch future regressions. [ghstack-poisoned]

int3 added a commit that referenced this pull request Dec 12, 2023

Fix c10::div_floor_floating compile error

e0a0c31

Introduced by #113276. I've added a test to catch future regressions. ghstack-source-id: ef8cda1 Pull Request resolved: #115647

int3 added a commit that referenced this pull request Dec 18, 2023

Fix c10::div_floor_floating compile error

90b3115

Introduced by #113276. I've added a test to catch future regressions. ghstack-source-id: 90f017e Pull Request resolved: #115647

int3 added a commit that referenced this pull request Dec 18, 2023

Update base for Update on "Fix c10::div_floor_floating compile error"

66382cb

Introduced by #113276. I've added a test to catch future regressions. [ghstack-poisoned]

int3 added a commit that referenced this pull request Dec 18, 2023

Update on "Fix c10::div_floor_floating compile error"

f997bb7

Introduced by #113276. I've added a test to catch future regressions. [ghstack-poisoned]


		} // namespace

		int64_t aoti_torch_div_floor_int64(int64_t a, int64_t b) {

[inductor] Enable floor_div indexing to work under ABI-compat mode #113276

[inductor] Enable floor_div indexing to work under ABI-compat mode #113276

Uh oh!

Conversation

int3 commented Nov 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pytorch-bot bot commented Nov 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

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

✅ No Failures

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swolchok Nov 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chenyang78 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

int3 commented Nov 10, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

desertfire Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

int3 Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

desertfire Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

int3 commented Nov 10, 2023

Uh oh!

pytorchmergebot commented Nov 10, 2023

Merge failed

Uh oh!

int3 commented Nov 10, 2023

Uh oh!

pytorchmergebot commented Nov 10, 2023

Merge started

Uh oh!

vfdev-5 commented Dec 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

int3 commented Nov 8, 2023 •

edited

Loading

pytorch-bot bot commented Nov 8, 2023 •

edited

Loading

swolchok Nov 9, 2023 •

edited

Loading

desertfire Nov 10, 2023 •

edited

Loading

int3 Nov 10, 2023 •

edited

Loading

desertfire Nov 10, 2023 •

edited

Loading

vfdev-5 commented Dec 12, 2023 •

edited

Loading