mirror of
https://github.com/pytorch/pytorch.git
synced 2025-10-20 12:54:11 +08:00
ec30d9028a
Summary: Pull Request resolved: https://github.com/pytorch/pytorch/pull/29731 The new structure is that libtorch_cpu contains the bulk of our code, and libtorch depends on libtorch_cpu and libtorch_cuda. Some subtleties about the patch: - There were a few functions that crossed CPU-CUDA boundary without API macros. I just added them, easy enough. An inverse situation was aten/src/THC/THCTensorRandom.cu where we weren't supposed to put API macros directly in a cpp file. - DispatchStub wasn't getting all of its symbols related to static members on DispatchStub exported properly. I tried a few fixes but in the end I just moved everyone off using DispatchStub to dispatch CUDA/HIP (so they just use normal dispatch for those cases.) Additionally, there were some mistakes where people incorrectly were failing to actually import the declaration of the dispatch stub, so added includes for those cases. - torch/csrc/cuda/nccl.cpp was added to the wrong list of SRCS, now fixed (this didn't matter before because previously they were all in the same library) - The dummy file for libtorch was brought back from the dead; it was previously deleted in #20774 - In an initial version of the patch, I forgot to make torch_cuda explicitly depend on torch_cpu. This lead to some very odd errors, most notably "bin/blob_test: hidden symbol `_ZNK6google8protobuf5Arena17OnArenaAllocationEPKSt9type_infom' in lib/l ibprotobuf.a(arena.cc.o) is referenced by DSO" - A number of places in Android/iOS builds have to add torch_cuda explicitly as a library, as they do not have transitive dependency calculation working correctly. This situation also happens with custom C++ extensions. - There's a ROCm compiler bug where extern "C" on functions is not respected. There's a little workaround to handle this. - Because I was too lazy to check if HIPify was converting TORCH_CUDA_API into TORCH_HIP_API, I just made it so HIP build also triggers the TORCH_CUDA_API macro. Eventually, we should translate and keep the nature of TORCH_CUDA_API constant in all cases. Fixes #27215 (as our libraries are smaller), and executes on part of the plan in #29235. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: Imported from OSS Differential Revision: D18632773 Pulled By: ezyang fbshipit-source-id: ea717c81e0d7554ede1dc404108603455a81da82
117 lines
4.1 KiB
C
117 lines
4.1 KiB
C
#ifndef C10_MACROS_EXPORT_H_
|
|
#define C10_MACROS_EXPORT_H_
|
|
|
|
/* Header file to define the common scaffolding for exported symbols.
|
|
*
|
|
* Export is by itself a quite tricky situation to deal with, and if you are
|
|
* hitting this file, make sure you start with the background here:
|
|
* - Linux: https://gcc.gnu.org/wiki/Visibility
|
|
* - Windows:
|
|
* https://docs.microsoft.com/en-us/cpp/cpp/dllexport-dllimport?view=vs-2017
|
|
*
|
|
* Do NOT include this file directly. Instead, use c10/macros/Macros.h
|
|
*/
|
|
|
|
// You do not need to edit this part of file unless you are changing the core
|
|
// pytorch export abstractions.
|
|
//
|
|
// This part defines the C10 core export and import macros. This is controlled
|
|
// by whether we are building shared libraries or not, which is determined
|
|
// during build time and codified in c10/core/cmake_macros.h.
|
|
// When the library is built as a shared lib, EXPORT and IMPORT will contain
|
|
// visibility attributes. If it is being built as a static lib, then EXPORT
|
|
// and IMPORT basically have no effect.
|
|
|
|
// As a rule of thumb, you should almost NEVER mix static and shared builds for
|
|
// libraries that depend on c10. AKA, if c10 is built as a static library, we
|
|
// recommend everything dependent on c10 to be built statically. If c10 is built
|
|
// as a shared library, everything dependent on it should be built as shared. In
|
|
// the PyTorch project, all native libraries shall use the macro
|
|
// C10_BUILD_SHARED_LIB to check whether pytorch is building shared or static
|
|
// libraries.
|
|
|
|
// For build systems that do not directly depend on CMake and directly build
|
|
// from the source directory (such as Buck), one may not have a cmake_macros.h
|
|
// file at all. In this case, the build system is responsible for providing
|
|
// correct macro definitions corresponding to the cmake_macros.h.in file.
|
|
//
|
|
// In such scenarios, one should define the macro
|
|
// C10_USING_CUSTOM_GENERATED_MACROS
|
|
// to inform this header that it does not need to include the cmake_macros.h
|
|
// file.
|
|
|
|
#ifndef C10_USING_CUSTOM_GENERATED_MACROS
|
|
#include "c10/macros/cmake_macros.h"
|
|
#endif // C10_USING_CUSTOM_GENERATED_MACROS
|
|
|
|
#ifdef _WIN32
|
|
#define C10_HIDDEN
|
|
#if defined(C10_BUILD_SHARED_LIBS)
|
|
#define C10_EXPORT __declspec(dllexport)
|
|
#define C10_IMPORT __declspec(dllimport)
|
|
#else
|
|
#define C10_EXPORT
|
|
#define C10_IMPORT
|
|
#endif
|
|
#else // _WIN32
|
|
#if defined(__GNUC__)
|
|
#define C10_EXPORT __attribute__((__visibility__("default")))
|
|
#define C10_HIDDEN __attribute__((__visibility__("hidden")))
|
|
#else // defined(__GNUC__)
|
|
#define C10_EXPORT
|
|
#define C10_HIDDEN
|
|
#endif // defined(__GNUC__)
|
|
#define C10_IMPORT C10_EXPORT
|
|
#endif // _WIN32
|
|
|
|
#ifdef NO_EXPORT
|
|
#undef C10_EXPORT
|
|
#define C10_EXPORT
|
|
#endif
|
|
|
|
// Definition of an adaptive XX_API macro, that depends on whether you are
|
|
// building the library itself or not, routes to XX_EXPORT and XX_IMPORT.
|
|
// Basically, you will need to do this for each shared library that you are
|
|
// building, and the instruction is as follows: assuming that you are building
|
|
// a library called libawesome.so. You should:
|
|
// (1) for your cmake target (usually done by "add_library(awesome, ...)"),
|
|
// define a macro called AWESOME_BUILD_MAIN_LIB using
|
|
// target_compile_options.
|
|
// (2) define the AWESOME_API macro similar to the one below.
|
|
// And in the source file of your awesome library, use AWESOME_API to
|
|
// annotate public symbols.
|
|
|
|
// Here, for the C10 library, we will define the macro C10_API for both import
|
|
// and export.
|
|
|
|
// This one is being used by libc10.so
|
|
#ifdef C10_BUILD_MAIN_LIB
|
|
#define C10_API C10_EXPORT
|
|
#else
|
|
#define C10_API C10_IMPORT
|
|
#endif
|
|
|
|
// This one is being used by libtorch.so
|
|
// TODO: rename this to TORCH_API
|
|
#ifdef CAFFE2_BUILD_MAIN_LIB
|
|
#define CAFFE2_API C10_EXPORT
|
|
#else
|
|
#define CAFFE2_API C10_IMPORT
|
|
#endif
|
|
|
|
// NB: For now, HIP is overloaded to use the same macro, but ideally
|
|
// HIPify should translate TORCH_CUDA_API to TORCH_HIP_API
|
|
#if defined(TORCH_CUDA_BUILD_MAIN_LIB) || defined(TORCH_HIP_BUILD_MAIN_LIB)
|
|
#define TORCH_CUDA_API C10_EXPORT
|
|
#else
|
|
#define TORCH_CUDA_API C10_IMPORT
|
|
#endif
|
|
|
|
#if defined(TORCH_HIP_BUILD_MAIN_LIB)
|
|
#define TORCH_HIP_API C10_EXPORT
|
|
#else
|
|
#define TORCH_HIP_API C10_IMPORT
|
|
#endif
|
|
|
|
#endif // C10_MACROS_MACROS_H_
|