maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Basic/Targets/AMDGPU.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

420 lines
16 KiB
C++
Raw Normal View History

Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
//===--- AMDGPU.cpp - Implement AMDGPU target feature support -------------===//
//
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
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements AMDGPU TargetInfo objects.
//
//===----------------------------------------------------------------------===//
#include "AMDGPU.h"
#include "clang/Basic/Builtins.h"
Move CodeGenOptions from Frontend to Basic Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
2018-12-11 11:18:39 +08:00
#include "clang/Basic/CodeGenOptions.h"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
#include "clang/Basic/LangOptions.h"
#include "clang/Basic/MacroBuilder.h"
#include "clang/Basic/TargetBuiltins.h"
#include "llvm/ADT/StringSwitch.h"
[OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 2 Summary: New file include to support platform dependent grid constants. It will be used by clang, libomptarget plugins, and deviceRTLs to access constant values consistently and with fast access in the deviceRTLs. Originally authored by Greg Rodgers (@gregrodgers). Reviewers: arsenm, sameerds, jdoerfert, yaxunl, b-sumner, scchan, JonChesterfield Reviewed By: arsenm Subscribers: llvm-commits, pdhaliwal, jholewinski, jvesely, wdng, nhaehnle, guansong, kerbowa, sstefan1, cfe-commits, ronlieb, gregrodgers Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80917
2020-06-11 01:58:15 +08:00
#include "llvm/Frontend/OpenMP/OMPGridValues.h"
Prune include of DataLayout.h from include/clang/Basic/TargetInfo.h. NFC Summary: Use a forward declaration of DataLayout instead of including DataLayout.h in clangs TargetInfo.h. This reduces include dependencies toward DataLayout.h (and other headers such as DerivedTypes.h, Type.h that is included by DataLayout.h). Needed to move implemantation of TargetInfo::resetDataLayout from TargetInfo.h to TargetInfo.cpp. Reviewers: rnk Reviewed By: rnk Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69262 llvm-svn: 375438
2019-10-22 01:58:14 +08:00
#include "llvm/IR/DataLayout.h"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
using namespace clang;
using namespace clang::targets;
namespace clang {
namespace targets {
// If you edit the description strings, make sure you update
// getPointerWidthV().
static const char *const DataLayoutStringR600 =
"e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128"
AMDGPU: Update datalayout for stack alignment llvm-svn: 328657
2018-03-28 03:26:51 +08:00
"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5";
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
static const char *const DataLayoutStringAMDGCN =
[AMDGPU] Change constant addr space to 4 Differential Revision: https://reviews.llvm.org/D43171 llvm-svn: 325031
2018-02-14 02:01:21 +08:00
"e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
"-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128"
[AMDGPU] Add the missing clang change of the experimental buffer fat pointer llvm-svn: 356385
2019-03-19 02:11:37 +08:00
"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5"
"-ni:7";
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
const LangASMap AMDGPUTargetInfo::AMDGPUDefIsGenMap = {
Generic, // Default
Global, // opencl_global
Local, // opencl_local
Constant, // opencl_constant
Private, // opencl_private
Generic, // opencl_generic
[OpenCL] Add global_device and global_host address spaces This patch introduces 2 new address spaces in OpenCL: global_device and global_host which are a subset of a global address space, so the address space scheme will be looking like: ``` generic->global->host ->device ->private ->local constant ``` Justification: USM allocations may be associated with both host and device memory. We want to give users a way to tell the compiler the allocation type of a USM pointer for optimization purposes. (Link to the Unified Shared Memory extension: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/cl_intel_unified_shared_memory.asciidoc) Before this patch USM pointer could be only in opencl_global address space, hence a device backend can't tell if a particular pointer points to host or device memory. On FPGAs at least we can generate more efficient hardware code if the user tells us where the pointer can point - being able to distinguish between these types of pointers at compile time allows us to instantiate simpler load-store units to perform memory transactions. Patch by Dmitry Sidorov. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D82174
2020-07-29 20:07:06 +08:00
Global, // opencl_global_device
Global, // opencl_global_host
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
Global, // cuda_device
Constant, // cuda_constant
Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr. Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
2019-10-25 07:34:25 +08:00
Local, // cuda_shared
Generic, // ptr32_sptr
Generic, // ptr32_uptr
Generic // ptr64
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
};
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
const LangASMap AMDGPUTargetInfo::AMDGPUDefIsPrivMap = {
Private, // Default
Global, // opencl_global
Local, // opencl_local
Constant, // opencl_constant
Private, // opencl_private
Generic, // opencl_generic
[OpenCL] Add global_device and global_host address spaces This patch introduces 2 new address spaces in OpenCL: global_device and global_host which are a subset of a global address space, so the address space scheme will be looking like: ``` generic->global->host ->device ->private ->local constant ``` Justification: USM allocations may be associated with both host and device memory. We want to give users a way to tell the compiler the allocation type of a USM pointer for optimization purposes. (Link to the Unified Shared Memory extension: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/cl_intel_unified_shared_memory.asciidoc) Before this patch USM pointer could be only in opencl_global address space, hence a device backend can't tell if a particular pointer points to host or device memory. On FPGAs at least we can generate more efficient hardware code if the user tells us where the pointer can point - being able to distinguish between these types of pointers at compile time allows us to instantiate simpler load-store units to perform memory transactions. Patch by Dmitry Sidorov. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D82174
2020-07-29 20:07:06 +08:00
Global, // opencl_global_device
Global, // opencl_global_host
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
Global, // cuda_device
Constant, // cuda_constant
Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr. Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
2019-10-25 07:34:25 +08:00
Local, // cuda_shared
Generic, // ptr32_sptr
Generic, // ptr32_uptr
Generic // ptr64
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
};
} // namespace targets
} // namespace clang
const Builtin::Info AMDGPUTargetInfo::BuiltinInfo[] = {
#define BUILTIN(ID, TYPE, ATTRS) \
{#ID, TYPE, ATTRS, nullptr, ALL_LANGUAGES, nullptr},
#define TARGET_BUILTIN(ID, TYPE, ATTRS, FEATURE) \
{#ID, TYPE, ATTRS, nullptr, ALL_LANGUAGES, FEATURE},
#include "clang/Basic/BuiltinsAMDGPU.def"
};
const char *const AMDGPUTargetInfo::GCCRegNames[] = {
"v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8",
"v9", "v10", "v11", "v12", "v13", "v14", "v15", "v16", "v17",
"v18", "v19", "v20", "v21", "v22", "v23", "v24", "v25", "v26",
"v27", "v28", "v29", "v30", "v31", "v32", "v33", "v34", "v35",
"v36", "v37", "v38", "v39", "v40", "v41", "v42", "v43", "v44",
"v45", "v46", "v47", "v48", "v49", "v50", "v51", "v52", "v53",
"v54", "v55", "v56", "v57", "v58", "v59", "v60", "v61", "v62",
"v63", "v64", "v65", "v66", "v67", "v68", "v69", "v70", "v71",
"v72", "v73", "v74", "v75", "v76", "v77", "v78", "v79", "v80",
"v81", "v82", "v83", "v84", "v85", "v86", "v87", "v88", "v89",
"v90", "v91", "v92", "v93", "v94", "v95", "v96", "v97", "v98",
"v99", "v100", "v101", "v102", "v103", "v104", "v105", "v106", "v107",
"v108", "v109", "v110", "v111", "v112", "v113", "v114", "v115", "v116",
"v117", "v118", "v119", "v120", "v121", "v122", "v123", "v124", "v125",
"v126", "v127", "v128", "v129", "v130", "v131", "v132", "v133", "v134",
"v135", "v136", "v137", "v138", "v139", "v140", "v141", "v142", "v143",
"v144", "v145", "v146", "v147", "v148", "v149", "v150", "v151", "v152",
"v153", "v154", "v155", "v156", "v157", "v158", "v159", "v160", "v161",
"v162", "v163", "v164", "v165", "v166", "v167", "v168", "v169", "v170",
"v171", "v172", "v173", "v174", "v175", "v176", "v177", "v178", "v179",
"v180", "v181", "v182", "v183", "v184", "v185", "v186", "v187", "v188",
"v189", "v190", "v191", "v192", "v193", "v194", "v195", "v196", "v197",
"v198", "v199", "v200", "v201", "v202", "v203", "v204", "v205", "v206",
"v207", "v208", "v209", "v210", "v211", "v212", "v213", "v214", "v215",
"v216", "v217", "v218", "v219", "v220", "v221", "v222", "v223", "v224",
"v225", "v226", "v227", "v228", "v229", "v230", "v231", "v232", "v233",
"v234", "v235", "v236", "v237", "v238", "v239", "v240", "v241", "v242",
"v243", "v244", "v245", "v246", "v247", "v248", "v249", "v250", "v251",
"v252", "v253", "v254", "v255", "s0", "s1", "s2", "s3", "s4",
"s5", "s6", "s7", "s8", "s9", "s10", "s11", "s12", "s13",
"s14", "s15", "s16", "s17", "s18", "s19", "s20", "s21", "s22",
"s23", "s24", "s25", "s26", "s27", "s28", "s29", "s30", "s31",
"s32", "s33", "s34", "s35", "s36", "s37", "s38", "s39", "s40",
"s41", "s42", "s43", "s44", "s45", "s46", "s47", "s48", "s49",
"s50", "s51", "s52", "s53", "s54", "s55", "s56", "s57", "s58",
"s59", "s60", "s61", "s62", "s63", "s64", "s65", "s66", "s67",
"s68", "s69", "s70", "s71", "s72", "s73", "s74", "s75", "s76",
"s77", "s78", "s79", "s80", "s81", "s82", "s83", "s84", "s85",
"s86", "s87", "s88", "s89", "s90", "s91", "s92", "s93", "s94",
"s95", "s96", "s97", "s98", "s99", "s100", "s101", "s102", "s103",
"s104", "s105", "s106", "s107", "s108", "s109", "s110", "s111", "s112",
"s113", "s114", "s115", "s116", "s117", "s118", "s119", "s120", "s121",
"s122", "s123", "s124", "s125", "s126", "s127", "exec", "vcc", "scc",
AMDGPU: Update for datalayout change llvm-svn: 324748
2018-02-10 00:58:41 +08:00
"m0", "flat_scratch", "exec_lo", "exec_hi", "vcc_lo", "vcc_hi",
[AMDGPU] Allow AGPR in inline asm Differential Revision: https://reviews.llvm.org/D77329
2020-04-03 05:16:03 +08:00
"flat_scratch_lo", "flat_scratch_hi",
"a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7", "a8",
"a9", "a10", "a11", "a12", "a13", "a14", "a15", "a16", "a17",
"a18", "a19", "a20", "a21", "a22", "a23", "a24", "a25", "a26",
"a27", "a28", "a29", "a30", "a31", "a32", "a33", "a34", "a35",
"a36", "a37", "a38", "a39", "a40", "a41", "a42", "a43", "a44",
"a45", "a46", "a47", "a48", "a49", "a50", "a51", "a52", "a53",
"a54", "a55", "a56", "a57", "a58", "a59", "a60", "a61", "a62",
"a63", "a64", "a65", "a66", "a67", "a68", "a69", "a70", "a71",
"a72", "a73", "a74", "a75", "a76", "a77", "a78", "a79", "a80",
"a81", "a82", "a83", "a84", "a85", "a86", "a87", "a88", "a89",
"a90", "a91", "a92", "a93", "a94", "a95", "a96", "a97", "a98",
"a99", "a100", "a101", "a102", "a103", "a104", "a105", "a106", "a107",
"a108", "a109", "a110", "a111", "a112", "a113", "a114", "a115", "a116",
"a117", "a118", "a119", "a120", "a121", "a122", "a123", "a124", "a125",
"a126", "a127", "a128", "a129", "a130", "a131", "a132", "a133", "a134",
"a135", "a136", "a137", "a138", "a139", "a140", "a141", "a142", "a143",
"a144", "a145", "a146", "a147", "a148", "a149", "a150", "a151", "a152",
"a153", "a154", "a155", "a156", "a157", "a158", "a159", "a160", "a161",
"a162", "a163", "a164", "a165", "a166", "a167", "a168", "a169", "a170",
"a171", "a172", "a173", "a174", "a175", "a176", "a177", "a178", "a179",
"a180", "a181", "a182", "a183", "a184", "a185", "a186", "a187", "a188",
"a189", "a190", "a191", "a192", "a193", "a194", "a195", "a196", "a197",
"a198", "a199", "a200", "a201", "a202", "a203", "a204", "a205", "a206",
"a207", "a208", "a209", "a210", "a211", "a212", "a213", "a214", "a215",
"a216", "a217", "a218", "a219", "a220", "a221", "a222", "a223", "a224",
"a225", "a226", "a227", "a228", "a229", "a230", "a231", "a232", "a233",
"a234", "a235", "a236", "a237", "a238", "a239", "a240", "a241", "a242",
"a243", "a244", "a245", "a246", "a247", "a248", "a249", "a250", "a251",
"a252", "a253", "a254", "a255"
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
};
ArrayRef<const char *> AMDGPUTargetInfo::getGCCRegNames() const {
return llvm::makeArrayRef(GCCRegNames);
}
bool AMDGPUTargetInfo::initFeatureMap(
llvm::StringMap<bool> &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector<std::string> &FeatureVec) const {
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
using namespace llvm::AMDGPU;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
// XXX - What does the member GPU mean if device name string passed here?
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
if (isAMDGCN(getTriple())) {
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
switch (llvm::AMDGPU::parseArchAMDGCN(CPU)) {
[AMDGPU] gfx1031 target Differential Revision: https://reviews.llvm.org/D85337
2020-08-06 03:00:52 +08:00
case GK_GFX1031:
[AMDGPU] Add gfx1030 target Differential Revision: https://reviews.llvm.org/D81886
2020-06-16 05:10:39 +08:00
case GK_GFX1030:
Features["ci-insts"] = true;
Features["dot1-insts"] = true;
Features["dot2-insts"] = true;
Features["dot5-insts"] = true;
Features["dot6-insts"] = true;
Features["dl-insts"] = true;
Features["flat-address-space"] = true;
Features["16-bit-insts"] = true;
Features["dpp"] = true;
Features["gfx8-insts"] = true;
Features["gfx9-insts"] = true;
Features["gfx10-insts"] = true;
Features["gfx10-3-insts"] = true;
Features["s-memrealtime"] = true;
break;
[AMDGPU] gfx1011/gfx1012 clang support Differential Revision: https://reviews.llvm.org/D63308 llvm-svn: 363345
2019-06-14 08:33:59 +08:00
case GK_GFX1012:
case GK_GFX1011:
Features["dot1-insts"] = true;
Features["dot2-insts"] = true;
Features["dot5-insts"] = true;
Features["dot6-insts"] = true;
LLVM_FALLTHROUGH;
[AMDGPU] gfx1010 clang target Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
2019-05-14 07:15:59 +08:00
case GK_GFX1010:
Features["dl-insts"] = true;
AMDGPU: Fix target builtins for gfx10 This wasn't setting some of the features from older generations. llvm-svn: 364123
2019-06-22 09:30:00 +08:00
Features["ci-insts"] = true;
AMDGPU: Add builtins for is_shared/is_private llvm-svn: 371010
2019-09-05 11:00:43 +08:00
Features["flat-address-space"] = true;
[AMDGPU] gfx1010 clang target Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
2019-05-14 07:15:59 +08:00
Features["16-bit-insts"] = true;
Features["dpp"] = true;
AMDGPU: Fix target builtins for gfx10 This wasn't setting some of the features from older generations. llvm-svn: 364123
2019-06-22 09:30:00 +08:00
Features["gfx8-insts"] = true;
[AMDGPU] gfx1010 clang target Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
2019-05-14 07:15:59 +08:00
Features["gfx9-insts"] = true;
Features["gfx10-insts"] = true;
Features["s-memrealtime"] = true;
break;
[AMDGPU] gfx908 clang target Differential Revision: https://reviews.llvm.org/D64430 llvm-svn: 365528
2019-07-10 02:19:00 +08:00
case GK_GFX908:
Features["dot3-insts"] = true;
Features["dot4-insts"] = true;
Features["dot5-insts"] = true;
Features["dot6-insts"] = true;
Summary: This CL adds clang declarations of built-in functions for AMDGPU MFMA intrinsics and instructions. OpenCL tests for new built-ins are included. Differential Revision: https://reviews.llvm.org/D72723
2020-01-28 16:51:27 +08:00
Features["mai-insts"] = true;
[AMDGPU] gfx908 clang target Differential Revision: https://reviews.llvm.org/D64430 llvm-svn: 365528
2019-07-10 02:19:00 +08:00
LLVM_FALLTHROUGH;
AMDGPU: Add Vega12 and Vega20 Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
2018-05-01 03:08:27 +08:00
case GK_GFX906:
Features["dl-insts"] = true;
[AMDGPU] Split dot-insts feature Differential Revision: https://reviews.llvm.org/D57972 llvm-svn: 353588
2019-02-09 08:34:41 +08:00
Features["dot1-insts"] = true;
Features["dot2-insts"] = true;
AMDGPU: Add Vega12 and Vega20 Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
2018-05-01 03:08:27 +08:00
LLVM_FALLTHROUGH;
AMDGPU: Handle gfx909 in AMDGPUTargetInfo::initFeatureMap + add required tests llvm-svn: 345181
2018-10-25 03:07:56 +08:00
case GK_GFX909:
AMDGPU: Add Vega12 and Vega20 Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
2018-05-01 03:08:27 +08:00
case GK_GFX904:
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_GFX902:
case GK_GFX900:
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Features["gfx9-insts"] = true;
LLVM_FALLTHROUGH;
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_GFX810:
case GK_GFX803:
case GK_GFX802:
case GK_GFX801:
[AMDGPU] rename vi-insts into gfx8-insts Differential Revision: https://reviews.llvm.org/D60293 llvm-svn: 357792
2019-04-06 02:25:00 +08:00
Features["gfx8-insts"] = true;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Features["16-bit-insts"] = true;
Features["dpp"] = true;
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
Features["s-memrealtime"] = true;
AMDGPU: Add builtin for s_dcache_inv_vol llvm-svn: 339109
2018-08-07 15:49:04 +08:00
LLVM_FALLTHROUGH;
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_GFX704:
case GK_GFX703:
case GK_GFX702:
case GK_GFX701:
case GK_GFX700:
AMDGPU: Add builtin for s_dcache_inv_vol llvm-svn: 339109
2018-08-07 15:49:04 +08:00
Features["ci-insts"] = true;
AMDGPU: Add builtins for is_shared/is_private llvm-svn: 371010
2019-09-05 11:00:43 +08:00
Features["flat-address-space"] = true;
AMDGPU: Add builtin for s_dcache_inv_vol llvm-svn: 339109
2018-08-07 15:49:04 +08:00
LLVM_FALLTHROUGH;
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_GFX601:
case GK_GFX600:
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
break;
case GK_NONE:
[AMDGPU] Do not assume a default GCN target Differential Revision: https://reviews.llvm.org/D66246 llvm-svn: 368917
2019-08-15 04:55:15 +08:00
break;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
default:
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
llvm_unreachable("Unhandled GPU!");
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
} else {
if (CPU.empty())
CPU = "r600";
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
switch (llvm::AMDGPU::parseArchR600(CPU)) {
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
case GK_CAYMAN:
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_CYPRESS:
case GK_RV770:
case GK_RV670:
AMDGPU: Don't add fp64 feature to r600 subtargets Should fix test after r319709 llvm-svn: 319735
2017-12-05 11:51:26 +08:00
// TODO: Add fp64 when implemented.
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
break;
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
case GK_TURKS:
case GK_CAICOS:
case GK_BARTS:
case GK_SUMO:
case GK_REDWOOD:
case GK_JUNIPER:
case GK_CEDAR:
case GK_RV730:
case GK_RV710:
case GK_RS880:
case GK_R630:
case GK_R600:
break;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
default:
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
llvm_unreachable("Unhandled GPU!");
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
}
return TargetInfo::initFeatureMap(Features, Diags, CPU, FeatureVec);
}
Add Rest of Targets Support to ValidCPUList (enabling march notes) A followup to: https://reviews.llvm.org/D42978 Most of the rest of the Targets were pretty rote, so this patch knocks them all out at once. Differential Revision: https://reviews.llvm.org/D43057 llvm-svn: 324676
2018-02-09 07:16:55 +08:00
void AMDGPUTargetInfo::fillValidCPUList(
SmallVectorImpl<StringRef> &Values) const {
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
if (isAMDGCN(getTriple()))
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
llvm::AMDGPU::fillValidArchListAMDGCN(Values);
Add Rest of Targets Support to ValidCPUList (enabling march notes) A followup to: https://reviews.llvm.org/D42978 Most of the rest of the Targets were pretty rote, so this patch knocks them all out at once. Differential Revision: https://reviews.llvm.org/D43057 llvm-svn: 324676
2018-02-09 07:16:55 +08:00
else
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
llvm::AMDGPU::fillValidArchListR600(Values);
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
void AMDGPUTargetInfo::setAddressSpaceMap(bool DefaultIsPrivate) {
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
AddrSpaceMap = DefaultIsPrivate ? &AMDGPUDefIsPrivMap : &AMDGPUDefIsGenMap;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
AMDGPUTargetInfo::AMDGPUTargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
: TargetInfo(Triple),
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
GPUKind(isAMDGCN(Triple) ?
llvm::AMDGPU::parseArchAMDGCN(Opts.CPU) :
llvm::AMDGPU::parseArchR600(Opts.CPU)),
GPUFeatures(isAMDGCN(Triple) ?
llvm::AMDGPU::getArchAttrAMDGCN(GPUKind) :
llvm::AMDGPU::getArchAttrR600(GPUKind)) {
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
resetDataLayout(isAMDGCN(getTriple()) ? DataLayoutStringAMDGCN
: DataLayoutStringR600);
assert(DataLayout->getAllocaAddrSpace() == Private);
[OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 2 Summary: New file include to support platform dependent grid constants. It will be used by clang, libomptarget plugins, and deviceRTLs to access constant values consistently and with fast access in the deviceRTLs. Originally authored by Greg Rodgers (@gregrodgers). Reviewers: arsenm, sameerds, jdoerfert, yaxunl, b-sumner, scchan, JonChesterfield Reviewed By: arsenm Subscribers: llvm-commits, pdhaliwal, jholewinski, jvesely, wdng, nhaehnle, guansong, kerbowa, sstefan1, cfe-commits, ronlieb, gregrodgers Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80917
2020-06-11 01:58:15 +08:00
GridValues = llvm::omp::AMDGPUGpuGridValues;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
setAddressSpaceMap(Triple.getOS() == llvm::Triple::Mesa3D ||
!isAMDGCN(Triple));
UseAddrSpaceMapMangling = true;
AMDGPU: Enable _Float16 llvm-svn: 359594
2019-05-01 02:35:37 +08:00
HasLegalHalfType = true;
HasFloat16 = true;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
// Set pointer width and alignment for target address space 0.
PointerWidth = PointerAlign = DataLayout->getPointerSizeInBits();
if (getMaxPointerWidth() == 64) {
LongWidth = LongAlign = 64;
SizeType = UnsignedLong;
PtrDiffType = SignedLong;
IntPtrType = SignedLong;
}
Add OpenCL 2.0 atomic builtin functions as Clang builtin OpenCL 2.0 atomic builtin functions have a scope argument which is ideally represented as synchronization scope argument in LLVM atomic instructions. Clang supports translating Clang atomic builtin functions to LLVM atomic instructions. However it currently does not support synchronization scope of LLVM atomic instructions. Without this, users have to use LLVM assembly code to implement OpenCL atomic builtin functions. This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin functions, which supports generating LLVM atomic instructions with synchronization scope operand. Currently only constant memory scope argument is supported. Support of non-constant memory scope argument will be added later. Differential Revision: https://reviews.llvm.org/D28691 llvm-svn: 310082
2017-08-05 02:16:31 +08:00
MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
void AMDGPUTargetInfo::adjust(LangOptions &Opts) {
TargetInfo::adjust(Opts);
[AMDGPU] Clean up old address space mapping and fix constant address space value Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
2018-03-06 01:50:10 +08:00
// ToDo: There are still a few places using default address space as private
// address space in OpenCL, which needs to be cleaned up, then Opts.OpenCL
// can be removed from the following line.
setAddressSpaceMap(/*DefaultIsPrivate=*/Opts.OpenCL ||
!isAMDGCN(getTriple()));
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
ArrayRef<Builtin::Info> AMDGPUTargetInfo::getTargetBuiltins() const {
return llvm::makeArrayRef(BuiltinInfo, clang::AMDGPU::LastTSBuiltin -
Builtin::FirstTSBuiltin);
}
void AMDGPUTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Reapply r325193 llvm-svn: 325203
2018-02-15 10:37:04 +08:00
Builder.defineMacro("__AMD__");
Builder.defineMacro("__AMDGPU__");
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
if (isAMDGCN(getTriple()))
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Builder.defineMacro("__AMDGCN__");
else
Builder.defineMacro("__R600__");
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (GPUKind != llvm::AMDGPU::GK_NONE) {
StringRef CanonName = isAMDGCN(getTriple()) ?
getArchNameAMDGCN(GPUKind) : getArchNameR600(GPUKind);
Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
[HIP] Support target id by --offload-arch This patch introduces support of target id by -offload-arch. Differential Revision: https://reviews.llvm.org/D60620
2020-05-05 11:22:06 +08:00
if (isAMDGCN(getTriple())) {
Builder.defineMacro("__amdgcn_processor__",
Twine("\"") + Twine(CanonName) + Twine("\""));
Builder.defineMacro("__amdgcn_target_id__",
Twine("\"") + Twine(getTargetID().getValue()) +
Twine("\""));
for (auto F : getAllPossibleTargetIDFeatures(getTriple(), CanonName)) {
auto Loc = OffloadArchFeatures.find(F);
if (Loc != OffloadArchFeatures.end()) {
std::string NewF = F.str();
std::replace(NewF.begin(), NewF.end(), '-', '_');
Builder.defineMacro(Twine("__amdgcn_feature_") + Twine(NewF) +
Twine("__"),
Loc->second ? "1" : "0");
}
}
}
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
}
Reapply r325193 llvm-svn: 325203
2018-02-15 10:37:04 +08:00
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
// TODO: __HAS_FMAF__, __HAS_LDEXPF__, __HAS_FP64__ are deprecated and will be
// removed in the near future.
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (hasFMAF())
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Builder.defineMacro("__HAS_FMAF__");
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (hasFastFMAF())
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
Builder.defineMacro("FP_FAST_FMAF");
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (hasLDEXPF())
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Builder.defineMacro("__HAS_LDEXPF__");
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (hasFP64())
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
Builder.defineMacro("__HAS_FP64__");
AMDGPU: Move target code into TargetParser llvm-svn: 340292
2018-08-22 00:13:29 +08:00
if (hasFastFMA())
AMDGPU: Define FP_FAST_FMA{F} macros for amdgcn - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
2018-02-28 05:48:05 +08:00
Builder.defineMacro("FP_FAST_FMA");
Break up Targets.cpp into a header/impl pair per target type[NFCI] Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
2017-07-22 06:37:03 +08:00
}
[HIP] Fix size_t for MSVC environment In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
2019-01-30 20:26:54 +08:00
void AMDGPUTargetInfo::setAuxTarget(const TargetInfo *Aux) {
Do not copy long double and 128-bit fp format from aux target for AMDGPU rC352620 caused regressions because it copied floating point format from aux target. floating point format decides whether extended long double is supported. It is x86_fp80 on x86 but IEEE double on amdgcn. Document usage of long doubel type in HIP programming guide https://github.com/ROCm-Developer-Tools/HIP/pull/890 Differential Revision: https://reviews.llvm.org/D57527 llvm-svn: 352801
2019-02-01 05:57:51 +08:00
assert(HalfFormat == Aux->HalfFormat);
assert(FloatFormat == Aux->FloatFormat);
assert(DoubleFormat == Aux->DoubleFormat);
// On x86_64 long double is 80-bit extended precision format, which is
// not supported by AMDGPU. 128-bit floating point format is also not
// supported by AMDGPU. Therefore keep its own format for these two types.
auto SaveLongDoubleFormat = LongDoubleFormat;
auto SaveFloat128Format = Float128Format;
[HIP] Fix size_t for MSVC environment In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
2019-01-30 20:26:54 +08:00
copyAuxTarget(Aux);
Do not copy long double and 128-bit fp format from aux target for AMDGPU rC352620 caused regressions because it copied floating point format from aux target. floating point format decides whether extended long double is supported. It is x86_fp80 on x86 but IEEE double on amdgcn. Document usage of long doubel type in HIP programming guide https://github.com/ROCm-Developer-Tools/HIP/pull/890 Differential Revision: https://reviews.llvm.org/D57527 llvm-svn: 352801
2019-02-01 05:57:51 +08:00
LongDoubleFormat = SaveLongDoubleFormat;
Float128Format = SaveFloat128Format;
[hip] Claim builtin type `__float128` supported if the host target supports it. Reviewers: tra, yaxunl Subscribers: jvesely, nhaehnle, kerbowa, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D78513
2020-04-21 03:15:05 +08:00
// For certain builtin types support on the host target, claim they are
// support to pass the compilation of the host code during the device-side
// compilation.
// FIXME: As the side effect, we also accept `__float128` uses in the device
// code. To rejct these builtin types supported in the host target but not in
// the device target, one approach would support `device_builtin` attribute
// so that we could tell the device builtin types from the host ones. The
// also solves the different representations of the same builtin type, such
// as `size_t` in the MSVC environment.
if (Aux->hasFloat128Type()) {
HasFloat128 = true;
Float128Format = DoubleFormat;
}
[HIP] Fix size_t for MSVC environment In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
2019-01-30 20:26:54 +08:00
}