llvm-project/parallel-libs/acxxel/config.h.in

//===--- config.h - Macros generated during configuration -------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
///
/// This file declares macros that are generated during the configuration stage
/// of the build.
///
//===----------------------------------------------------------------------===//

#cmakedefine ACXXEL_ENABLE_CUDA
#cmakedefine ACXXEL_ENABLE_OPENCL
Initial check-in of Acxxel (StreamExecutor renamed) Summary: Acxxel is basically a simplified redesign of StreamExecutor. Here are the major points where Acxxel differs from the current StreamExecutor design: * Acxxel doesn't support the kernel and kernel loader types designed for emission by the compiler to support type-safe kernel launches. For CUDA, kernels in Acxxel can be seamlessly launched using the standard CUDA triple-chevron kernel launch syntax that is available with clang and nvcc. For CUDA and OpenCL, kernel arguments can be passed in the old-fashioned way, as one array of pointers to arguments and another array of argument sizes. Although OpenCL doesn't get a type-safe kernel launch method, it does still get the benefit of all the memory management wrappers. In the future, clang may add support for triple-chevron OpenCL kernel launchs, or some other type-safe OpenCL kernel launch method. * Acxxel does not depend on any other code in LLVM, so it builds completely independently from LLVM. The goal will be to check in Acxxel and remove StreamExecutor, or perhaps to remove the old StreamExecutor and rename Acxxel to StreamExecutor, so I think Acxxel should be thought of as a new version of StreamExecutor, not as a separate project. Reviewers: jlebar, jprice Subscribers: beanz, mgorny, modocache, parallel_libs-commits Differential Revision: https://reviews.llvm.org/D25701 llvm-svn: 285111 2016-10-26 04:18:56 +08:00			`//===--- config.h - Macros generated during configuration -------- C++ --===//`
			`//`
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2019-01-19 16:50:56 +08:00			`// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.`
			`// See https://llvm.org/LICENSE.txt for license information.`
			`// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception`
Initial check-in of Acxxel (StreamExecutor renamed) Summary: Acxxel is basically a simplified redesign of StreamExecutor. Here are the major points where Acxxel differs from the current StreamExecutor design: * Acxxel doesn't support the kernel and kernel loader types designed for emission by the compiler to support type-safe kernel launches. For CUDA, kernels in Acxxel can be seamlessly launched using the standard CUDA triple-chevron kernel launch syntax that is available with clang and nvcc. For CUDA and OpenCL, kernel arguments can be passed in the old-fashioned way, as one array of pointers to arguments and another array of argument sizes. Although OpenCL doesn't get a type-safe kernel launch method, it does still get the benefit of all the memory management wrappers. In the future, clang may add support for triple-chevron OpenCL kernel launchs, or some other type-safe OpenCL kernel launch method. * Acxxel does not depend on any other code in LLVM, so it builds completely independently from LLVM. The goal will be to check in Acxxel and remove StreamExecutor, or perhaps to remove the old StreamExecutor and rename Acxxel to StreamExecutor, so I think Acxxel should be thought of as a new version of StreamExecutor, not as a separate project. Reviewers: jlebar, jprice Subscribers: beanz, mgorny, modocache, parallel_libs-commits Differential Revision: https://reviews.llvm.org/D25701 llvm-svn: 285111 2016-10-26 04:18:56 +08:00			`//`
			`//===----------------------------------------------------------------------===//`
			`///`
			`/// This file declares macros that are generated during the configuration stage`
			`/// of the build.`
			`///`
			`//===----------------------------------------------------------------------===//`

			`#cmakedefine ACXXEL_ENABLE_CUDA`
			`#cmakedefine ACXXEL_ENABLE_OPENCL`