mirror of
https://github.com/pytorch/pytorch.git
synced 2025-10-20 21:14:14 +08:00
Address richard's comments on libtorch_stable_abi note (#156324)
Followups from #155984 Pull Request resolved: https://github.com/pytorch/pytorch/pull/156324 Approved by: https://github.com/zou3519
This commit is contained in:
committed by
PyTorch MergeBot
parent
dcb97cd519
commit
4048a144ab
@ -30,16 +30,16 @@ This note will eventually contain more details on how to use the APIs in torch/c
|
||||
| ? | ? | c10::SymBool | SymBool |
|
||||
| ? | ? | at::QScheme | QScheme |
|
||||
|
||||
Our confidently supported types are the ones in the table that have completed rows. You can rely on this subset proper ABI stability.
|
||||
Our confidently supported types are the ones in the table that have completed rows. You can rely on this subset for proper ABI stability.
|
||||
|
||||
For a limited set of use cases, we also implicitly support any literal type that is representable within 64 bits as StableIValues, as the default reinterpret_cast will succeed. These types are currently ABI-stable on best effort but might break in the future and thus should be used for short term testing only.
|
||||
For a limited set of use cases, we also implicitly support any literal type that is representable within 64 bits as StableIValues, as the default reinterpret_cast will succeed. (For example: c10::Device.) These types are currently ABI-stable on best effort but might break in the future and thus should be used for short term testing only.
|
||||
|
||||
You can always work with StableIValue abstractions in your custom kernel for types such as c10::Device even if there is no standard defined representation of device in custom extensions by not introspecting into the StableIValue. For example, a custom operator can take as argument a StableIValue device and directly pass it through to an aten operator with `aoti_torch_call_dispatcher`.
|
||||
|
||||
|
||||
## How to use stack-based APIs
|
||||
|
||||
`aoti_torch_call_dispatcher` is what we consider a stack-based API because it takes as input a stack of StableIValues. Working with the dispatcher will likely bring you into proximity with stack-based APIs, so we are documenting some invariants:
|
||||
`aoti_torch_call_dispatcher` is what we consider a stack-based API because it takes as input a stack of StableIValues, which correlates with a `torch::jit::stack` of IValues. Working with the dispatcher will likely bring you into proximity with stack-based APIs, so we are documenting some invariants:
|
||||
|
||||
1. The stack is populated left to right.
|
||||
a. For example, a stack representing arguments `arg0`, `arg1`, and `arg2` will have `arg0` at index 0, `arg1` at index 1, and `arg2` at index 2.
|
||||
|
Reference in New Issue
Block a user