maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Support/TargetParser.cpp

207 lines
7.9 KiB
C++
Raw Normal View History

TargetParser: FPU/ARCH/EXT parsing refactory - NFC This new class in a global context contain arch-specific knowledge in order to provide LLVM libraries, tools and projects with the ability to understand the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are supported. Current behaviour it to parse from free-text to enum values and back, so that all users can share the same parser and codes. This simplifies a lot both the ASM/Obj streamers in the back-end (where this came from), and the front-end parsers for command line arguments (where this is going to be used next). The previous implementation, using .def/.h includes is deprecated due to its inflexibility to be built without the backend support and for being too cumbersome. As more architectures join this scheme, and as more features of such architectures are added (such as hardware features, type sizes, etc) into a full blown TargetDescription class, having a set of classes is the most sane implementation. The ultimate goal of this refactor both LLVM's and Clang's target description classes into one unique interface, so that we can de-duplicate and standardise the descriptions, as well as make it available for other front-ends, tools, etc. The FPU parsing for command line options in Clang has been converted to use this new library and a number of aliases were added for compatibility: * A bogus neon-vfpv3 alias (neon defaults to vfp3) * armv5/v6 * {fp4/fp5}-{sp/dp}-d16 Next steps: * Port Clang's ARCH/EXT parsing to use this library. * Create a TableGen back-end to generate this information. * Run this TableGen process regardless of which back-ends are built. * Expose more information and rename it to TargetDescription. * Continue re-factoring Clang to use as much of it as possible. llvm-svn: 236900
2015-05-09 05:04:27 +08:00
//===-- TargetParser - Parser for target features ---------------*- 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
TargetParser: FPU/ARCH/EXT parsing refactory - NFC This new class in a global context contain arch-specific knowledge in order to provide LLVM libraries, tools and projects with the ability to understand the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are supported. Current behaviour it to parse from free-text to enum values and back, so that all users can share the same parser and codes. This simplifies a lot both the ASM/Obj streamers in the back-end (where this came from), and the front-end parsers for command line arguments (where this is going to be used next). The previous implementation, using .def/.h includes is deprecated due to its inflexibility to be built without the backend support and for being too cumbersome. As more architectures join this scheme, and as more features of such architectures are added (such as hardware features, type sizes, etc) into a full blown TargetDescription class, having a set of classes is the most sane implementation. The ultimate goal of this refactor both LLVM's and Clang's target description classes into one unique interface, so that we can de-duplicate and standardise the descriptions, as well as make it available for other front-ends, tools, etc. The FPU parsing for command line options in Clang has been converted to use this new library and a number of aliases were added for compatibility: * A bogus neon-vfpv3 alias (neon defaults to vfp3) * armv5/v6 * {fp4/fp5}-{sp/dp}-d16 Next steps: * Port Clang's ARCH/EXT parsing to use this library. * Create a TableGen back-end to generate this information. * Run this TableGen process regardless of which back-ends are built. * Expose more information and rename it to TargetDescription. * Continue re-factoring Clang to use as much of it as possible. llvm-svn: 236900
2015-05-09 05:04:27 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements a target parser to recognise hardware features such as
// FPU/CPU/ARCH names as well as specific support such as HDIV, etc.
//
//===----------------------------------------------------------------------===//
#include "llvm/Support/ARMBuildAttributes.h"
#include "llvm/Support/TargetParser.h"
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
#include "llvm/ADT/ArrayRef.h"
TargetParser: FPU/ARCH/EXT parsing refactory - NFC This new class in a global context contain arch-specific knowledge in order to provide LLVM libraries, tools and projects with the ability to understand the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are supported. Current behaviour it to parse from free-text to enum values and back, so that all users can share the same parser and codes. This simplifies a lot both the ASM/Obj streamers in the back-end (where this came from), and the front-end parsers for command line arguments (where this is going to be used next). The previous implementation, using .def/.h includes is deprecated due to its inflexibility to be built without the backend support and for being too cumbersome. As more architectures join this scheme, and as more features of such architectures are added (such as hardware features, type sizes, etc) into a full blown TargetDescription class, having a set of classes is the most sane implementation. The ultimate goal of this refactor both LLVM's and Clang's target description classes into one unique interface, so that we can de-duplicate and standardise the descriptions, as well as make it available for other front-ends, tools, etc. The FPU parsing for command line options in Clang has been converted to use this new library and a number of aliases were added for compatibility: * A bogus neon-vfpv3 alias (neon defaults to vfp3) * armv5/v6 * {fp4/fp5}-{sp/dp}-d16 Next steps: * Port Clang's ARCH/EXT parsing to use this library. * Create a TableGen back-end to generate this information. * Run this TableGen process regardless of which back-ends are built. * Expose more information and rename it to TargetDescription. * Continue re-factoring Clang to use as much of it as possible. llvm-svn: 236900
2015-05-09 05:04:27 +08:00
#include "llvm/ADT/StringSwitch.h"
[ARM] Add +feature names to TargetParser extensions table llvm-svn: 253470
2015-11-19 00:32:12 +08:00
#include "llvm/ADT/Twine.h"
TargetParser: FPU/ARCH/EXT parsing refactory - NFC This new class in a global context contain arch-specific knowledge in order to provide LLVM libraries, tools and projects with the ability to understand the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are supported. Current behaviour it to parse from free-text to enum values and back, so that all users can share the same parser and codes. This simplifies a lot both the ASM/Obj streamers in the back-end (where this came from), and the front-end parsers for command line arguments (where this is going to be used next). The previous implementation, using .def/.h includes is deprecated due to its inflexibility to be built without the backend support and for being too cumbersome. As more architectures join this scheme, and as more features of such architectures are added (such as hardware features, type sizes, etc) into a full blown TargetDescription class, having a set of classes is the most sane implementation. The ultimate goal of this refactor both LLVM's and Clang's target description classes into one unique interface, so that we can de-duplicate and standardise the descriptions, as well as make it available for other front-ends, tools, etc. The FPU parsing for command line options in Clang has been converted to use this new library and a number of aliases were added for compatibility: * A bogus neon-vfpv3 alias (neon defaults to vfp3) * armv5/v6 * {fp4/fp5}-{sp/dp}-d16 Next steps: * Port Clang's ARCH/EXT parsing to use this library. * Create a TableGen back-end to generate this information. * Run this TableGen process regardless of which back-ends are built. * Expose more information and rename it to TargetDescription. * Continue re-factoring Clang to use as much of it as possible. llvm-svn: 236900
2015-05-09 05:04:27 +08:00
using namespace llvm;
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
using namespace AMDGPU;
TargetParser: FPU/ARCH/EXT parsing refactory - NFC This new class in a global context contain arch-specific knowledge in order to provide LLVM libraries, tools and projects with the ability to understand the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are supported. Current behaviour it to parse from free-text to enum values and back, so that all users can share the same parser and codes. This simplifies a lot both the ASM/Obj streamers in the back-end (where this came from), and the front-end parsers for command line arguments (where this is going to be used next). The previous implementation, using .def/.h includes is deprecated due to its inflexibility to be built without the backend support and for being too cumbersome. As more architectures join this scheme, and as more features of such architectures are added (such as hardware features, type sizes, etc) into a full blown TargetDescription class, having a set of classes is the most sane implementation. The ultimate goal of this refactor both LLVM's and Clang's target description classes into one unique interface, so that we can de-duplicate and standardise the descriptions, as well as make it available for other front-ends, tools, etc. The FPU parsing for command line options in Clang has been converted to use this new library and a number of aliases were added for compatibility: * A bogus neon-vfpv3 alias (neon defaults to vfp3) * armv5/v6 * {fp4/fp5}-{sp/dp}-d16 Next steps: * Port Clang's ARCH/EXT parsing to use this library. * Create a TableGen back-end to generate this information. * Run this TableGen process regardless of which back-ends are built. * Expose more information and rename it to TargetDescription. * Continue re-factoring Clang to use as much of it as possible. llvm-svn: 236900
2015-05-09 05:04:27 +08:00
namespace {
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
struct GPUInfo {
StringLiteral Name;
StringLiteral CanonicalName;
AMDGPU::GPUKind Kind;
unsigned Features;
};
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
constexpr GPUInfo R600GPUs[26] = {
// Name Canonical Kind Features
// Name
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
{{"r600"}, {"r600"}, GK_R600, FEATURE_NONE },
{{"rv630"}, {"r600"}, GK_R600, FEATURE_NONE },
{{"rv635"}, {"r600"}, GK_R600, FEATURE_NONE },
{{"r630"}, {"r630"}, GK_R630, FEATURE_NONE },
{{"rs780"}, {"rs880"}, GK_RS880, FEATURE_NONE },
{{"rs880"}, {"rs880"}, GK_RS880, FEATURE_NONE },
{{"rv610"}, {"rs880"}, GK_RS880, FEATURE_NONE },
{{"rv620"}, {"rs880"}, GK_RS880, FEATURE_NONE },
{{"rv670"}, {"rv670"}, GK_RV670, FEATURE_NONE },
{{"rv710"}, {"rv710"}, GK_RV710, FEATURE_NONE },
{{"rv730"}, {"rv730"}, GK_RV730, FEATURE_NONE },
{{"rv740"}, {"rv770"}, GK_RV770, FEATURE_NONE },
{{"rv770"}, {"rv770"}, GK_RV770, FEATURE_NONE },
{{"cedar"}, {"cedar"}, GK_CEDAR, FEATURE_NONE },
{{"palm"}, {"cedar"}, GK_CEDAR, FEATURE_NONE },
{{"cypress"}, {"cypress"}, GK_CYPRESS, FEATURE_FMA },
{{"hemlock"}, {"cypress"}, GK_CYPRESS, FEATURE_FMA },
{{"juniper"}, {"juniper"}, GK_JUNIPER, FEATURE_NONE },
{{"redwood"}, {"redwood"}, GK_REDWOOD, FEATURE_NONE },
{{"sumo"}, {"sumo"}, GK_SUMO, FEATURE_NONE },
{{"sumo2"}, {"sumo"}, GK_SUMO, FEATURE_NONE },
{{"barts"}, {"barts"}, GK_BARTS, FEATURE_NONE },
{{"caicos"}, {"caicos"}, GK_CAICOS, FEATURE_NONE },
{{"aruba"}, {"cayman"}, GK_CAYMAN, FEATURE_FMA },
{{"cayman"}, {"cayman"}, GK_CAYMAN, FEATURE_FMA },
{{"turks"}, {"turks"}, GK_TURKS, FEATURE_NONE }
};
// This table should be sorted by the value of GPUKind
// Don't bother listing the implicitly true features
[AMDGPU] gfx1011/gfx1012 targets Differential Revision: https://reviews.llvm.org/D63307 llvm-svn: 363344
2019-06-14 08:33:31 +08:00
constexpr GPUInfo AMDGCNGPUs[36] = {
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
// Name Canonical Kind Features
// Name
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
{{"gfx600"}, {"gfx600"}, GK_GFX600, FEATURE_FAST_FMA_F32},
{{"tahiti"}, {"gfx600"}, GK_GFX600, FEATURE_FAST_FMA_F32},
{{"gfx601"}, {"gfx601"}, GK_GFX601, FEATURE_NONE},
{{"hainan"}, {"gfx601"}, GK_GFX601, FEATURE_NONE},
{{"oland"}, {"gfx601"}, GK_GFX601, FEATURE_NONE},
{{"pitcairn"}, {"gfx601"}, GK_GFX601, FEATURE_NONE},
{{"verde"}, {"gfx601"}, GK_GFX601, FEATURE_NONE},
{{"gfx700"}, {"gfx700"}, GK_GFX700, FEATURE_NONE},
{{"kaveri"}, {"gfx700"}, GK_GFX700, FEATURE_NONE},
{{"gfx701"}, {"gfx701"}, GK_GFX701, FEATURE_FAST_FMA_F32},
{{"hawaii"}, {"gfx701"}, GK_GFX701, FEATURE_FAST_FMA_F32},
{{"gfx702"}, {"gfx702"}, GK_GFX702, FEATURE_FAST_FMA_F32},
{{"gfx703"}, {"gfx703"}, GK_GFX703, FEATURE_NONE},
{{"kabini"}, {"gfx703"}, GK_GFX703, FEATURE_NONE},
{{"mullins"}, {"gfx703"}, GK_GFX703, FEATURE_NONE},
{{"gfx704"}, {"gfx704"}, GK_GFX704, FEATURE_NONE},
{{"bonaire"}, {"gfx704"}, GK_GFX704, FEATURE_NONE},
{{"gfx801"}, {"gfx801"}, GK_GFX801, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"carrizo"}, {"gfx801"}, GK_GFX801, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"gfx802"}, {"gfx802"}, GK_GFX802, FEATURE_FAST_DENORMAL_F32},
{{"iceland"}, {"gfx802"}, GK_GFX802, FEATURE_FAST_DENORMAL_F32},
{{"tonga"}, {"gfx802"}, GK_GFX802, FEATURE_FAST_DENORMAL_F32},
{{"gfx803"}, {"gfx803"}, GK_GFX803, FEATURE_FAST_DENORMAL_F32},
{{"fiji"}, {"gfx803"}, GK_GFX803, FEATURE_FAST_DENORMAL_F32},
{{"polaris10"}, {"gfx803"}, GK_GFX803, FEATURE_FAST_DENORMAL_F32},
{{"polaris11"}, {"gfx803"}, GK_GFX803, FEATURE_FAST_DENORMAL_F32},
{{"gfx810"}, {"gfx810"}, GK_GFX810, FEATURE_FAST_DENORMAL_F32},
{{"stoney"}, {"gfx810"}, GK_GFX810, FEATURE_FAST_DENORMAL_F32},
{{"gfx900"}, {"gfx900"}, GK_GFX900, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"gfx902"}, {"gfx902"}, GK_GFX902, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"gfx904"}, {"gfx904"}, GK_GFX904, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"gfx906"}, {"gfx906"}, GK_GFX906, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
[AMDGPU] Defined gfx909 Raven Ridge 2 Differential Revision: https://reviews.llvm.org/D53418 Change-Id: Ie3d054f2e956c2768988c0f4c0ffd29a47294eef llvm-svn: 345120
2018-10-24 16:14:07 +08:00
{{"gfx909"}, {"gfx909"}, GK_GFX909, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
[AMDGPU] Add gfx1010 target definitions Differential Revision: https://reviews.llvm.org/D61041 llvm-svn: 359113
2019-04-25 01:03:15 +08:00
{{"gfx1010"}, {"gfx1010"}, GK_GFX1010, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
[AMDGPU] gfx1011/gfx1012 targets Differential Revision: https://reviews.llvm.org/D63307 llvm-svn: 363344
2019-06-14 08:33:31 +08:00
{{"gfx1011"}, {"gfx1011"}, GK_GFX1011, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
{{"gfx1012"}, {"gfx1012"}, GK_GFX1012, FEATURE_FAST_FMA_F32|FEATURE_FAST_DENORMAL_F32},
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
};
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
const GPUInfo *getArchEntry(AMDGPU::GPUKind AK, ArrayRef<GPUInfo> Table) {
Try to fix bot build failure llvm-svn: 340296
2018-08-22 00:24:56 +08:00
GPUInfo Search = { {""}, {""}, AK, AMDGPU::FEATURE_NONE };
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
auto I = std::lower_bound(Table.begin(), Table.end(), Search,
[](const GPUInfo &A, const GPUInfo &B) {
return A.Kind < B.Kind;
});
if (I == Table.end())
return nullptr;
return I;
}
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
} // namespace
AMDGPU: Partially move target handling code from clang to TargetParser A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-22 00:13:01 +08:00
StringRef llvm::AMDGPU::getArchNameAMDGCN(GPUKind AK) {
if (const auto *Entry = getArchEntry(AK, AMDGCNGPUs))
return Entry->CanonicalName;
return "";
}
StringRef llvm::AMDGPU::getArchNameR600(GPUKind AK) {
if (const auto *Entry = getArchEntry(AK, R600GPUs))
return Entry->CanonicalName;
return "";
}
AMDGPU::GPUKind llvm::AMDGPU::parseArchAMDGCN(StringRef CPU) {
for (const auto C : AMDGCNGPUs) {
if (CPU == C.Name)
return C.Kind;
}
return AMDGPU::GPUKind::GK_NONE;
}
AMDGPU::GPUKind llvm::AMDGPU::parseArchR600(StringRef CPU) {
for (const auto C : R600GPUs) {
if (CPU == C.Name)
return C.Kind;
}
return AMDGPU::GPUKind::GK_NONE;
}
unsigned AMDGPU::getArchAttrAMDGCN(GPUKind AK) {
if (const auto *Entry = getArchEntry(AK, AMDGCNGPUs))
return Entry->Features;
return FEATURE_NONE;
}
unsigned AMDGPU::getArchAttrR600(GPUKind AK) {
if (const auto *Entry = getArchEntry(AK, R600GPUs))
return Entry->Features;
return FEATURE_NONE;
}
void AMDGPU::fillValidArchListAMDGCN(SmallVectorImpl<StringRef> &Values) {
// XXX: Should this only report unique canonical names?
for (const auto C : AMDGCNGPUs)
Values.push_back(C.Name);
}
void AMDGPU::fillValidArchListR600(SmallVectorImpl<StringRef> &Values) {
for (const auto C : R600GPUs)
Values.push_back(C.Name);
}
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
AMDGPU::IsaVersion AMDGPU::getIsaVersion(StringRef GPU) {
AMDGPU::GPUKind AK = parseArchAMDGCN(GPU);
AMDGPU: Partially fix default device for HSA There are a few different issues, mostly stemming from using generation based checks for anything instead of subtarget features. Stop adding flat-address-space as a feature for HSA, as it should only be a device property. This was incorrectly allowing flat instructions to select for SI. Increase the default generation for HSA to avoid the encoding error when emitting objects. This has some other side effects from various checks which probably should be separate subtarget features (in the cost model and for dealing with the DS offset folding issue). Partial fix for bug 41070. It should probably be an error to try using amdhsa without flat support. llvm-svn: 356347
2019-03-18 05:31:35 +08:00
if (AK == AMDGPU::GPUKind::GK_NONE) {
if (GPU == "generic-hsa")
return {7, 0, 0};
if (GPU == "generic")
return {6, 0, 0};
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
return {0, 0, 0};
AMDGPU: Partially fix default device for HSA There are a few different issues, mostly stemming from using generation based checks for anything instead of subtarget features. Stop adding flat-address-space as a feature for HSA, as it should only be a device property. This was incorrectly allowing flat instructions to select for SI. Increase the default generation for HSA to avoid the encoding error when emitting objects. This has some other side effects from various checks which probably should be separate subtarget features (in the cost model and for dealing with the DS offset folding issue). Partial fix for bug 41070. It should probably be an error to try using amdhsa without flat support. llvm-svn: 356347
2019-03-18 05:31:35 +08:00
}
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
switch (AK) {
[AMDGPU] Add gfx1010 target definitions Differential Revision: https://reviews.llvm.org/D61041 llvm-svn: 359113
2019-04-25 01:03:15 +08:00
case GK_GFX600: return {6, 0, 0};
case GK_GFX601: return {6, 0, 1};
case GK_GFX700: return {7, 0, 0};
case GK_GFX701: return {7, 0, 1};
case GK_GFX702: return {7, 0, 2};
case GK_GFX703: return {7, 0, 3};
case GK_GFX704: return {7, 0, 4};
case GK_GFX801: return {8, 0, 1};
case GK_GFX802: return {8, 0, 2};
case GK_GFX803: return {8, 0, 3};
case GK_GFX810: return {8, 1, 0};
case GK_GFX900: return {9, 0, 0};
case GK_GFX902: return {9, 0, 2};
case GK_GFX904: return {9, 0, 4};
case GK_GFX906: return {9, 0, 6};
case GK_GFX909: return {9, 0, 9};
case GK_GFX1010: return {10, 1, 0};
[AMDGPU] gfx1011/gfx1012 targets Differential Revision: https://reviews.llvm.org/D63307 llvm-svn: 363344
2019-06-14 08:33:31 +08:00
case GK_GFX1011: return {10, 1, 1};
case GK_GFX1012: return {10, 1, 2};
[AMDGPU] Add gfx1010 target definitions Differential Revision: https://reviews.llvm.org/D61041 llvm-svn: 359113
2019-04-25 01:03:15 +08:00
default: return {0, 0, 0};
AMDGPU: Re-apply r341982 after fixing the layering issue Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-13 02:50:47 +08:00
}
}