-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[clang][SPIR-V] Add support for AMDGCN flavoured SPIRV #89796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
662f160
393ce66
2a10ad0
98db8f7
c359e0a
e98f3f5
c41726d
4698b58
aa1cd7c
f9729ef
8257cb1
900cd69
3307f17
eee6063
d2f4244
4cb4026
84a621d
1841385
0ce2da3
120b73c
f3942bd
31ac77d
0e9b1a1
83cd5e0
e9158b0
05074e7
e1fb93f
36c4bf6
5ffa186
cf1880c
4d85a1b
516e14c
bdc3eb5
361d47b
b088c72
e85b557
1d41787
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,7 +11,9 @@ | |
//===----------------------------------------------------------------------===// | ||
|
||
#include "SPIR.h" | ||
#include "AMDGPU.h" | ||
#include "Targets.h" | ||
#include "llvm/TargetParser/TargetParser.h" | ||
|
||
using namespace clang; | ||
using namespace clang::targets; | ||
|
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions &Opts, | |
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder); | ||
DefineStd(Builder, "SPIRV64", Opts); | ||
} | ||
|
||
static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {}); | ||
|
||
ArrayRef<const char *> SPIRV64AMDGCNTargetInfo::getGCCRegNames() const { | ||
return AMDGPUTI.getGCCRegNames(); | ||
} | ||
|
||
bool SPIRV64AMDGCNTargetInfo::initFeatureMap( | ||
llvm::StringMap<bool> &Features, DiagnosticsEngine &Diags, StringRef, | ||
const std::vector<std::string> &FeatureVec) const { | ||
llvm::AMDGPU::fillAMDGPUFeatureMap({}, getTriple(), Features); | ||
|
||
return TargetInfo::initFeatureMap(Features, Diags, {}, FeatureVec); | ||
} | ||
|
||
bool SPIRV64AMDGCNTargetInfo::validateAsmConstraint( | ||
const char *&Name, TargetInfo::ConstraintInfo &Info) const { | ||
return AMDGPUTI.validateAsmConstraint(Name, Info); | ||
} | ||
|
||
std::string | ||
SPIRV64AMDGCNTargetInfo::convertConstraint(const char *&Constraint) const { | ||
return AMDGPUTI.convertConstraint(Constraint); | ||
} | ||
|
||
ArrayRef<Builtin::Info> SPIRV64AMDGCNTargetInfo::getTargetBuiltins() const { | ||
return AMDGPUTI.getTargetBuiltins(); | ||
} | ||
|
||
void SPIRV64AMDGCNTargetInfo::getTargetDefines(const LangOptions &Opts, | ||
MacroBuilder &Builder) const { | ||
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder); | ||
DefineStd(Builder, "SPIRV64", Opts); | ||
|
||
Builder.defineMacro("__AMD__"); | ||
Builder.defineMacro("__AMDGPU__"); | ||
Builder.defineMacro("__AMDGCN__"); | ||
} | ||
|
||
void SPIRV64AMDGCNTargetInfo::setAuxTarget(const TargetInfo *Aux) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I can tell, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is a reasonable assumption. Since HIP/CUDA needs to make sure type consistency between host and device, normal compilation by clang driver always specify aux-target for device compilation. |
||
assert(Aux && "Cannot invoke setAuxTarget without a valid auxiliary target!"); | ||
|
||
// This is a 1:1 copy of AMDGPUTargetInfo::setAuxTarget() | ||
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; | ||
auto SaveLongDoubleWidth = LongDoubleWidth; | ||
auto SaveLongDoubleAlign = LongDoubleAlign; | ||
copyAuxTarget(Aux); | ||
LongDoubleFormat = SaveLongDoubleFormat; | ||
Float128Format = SaveFloat128Format; | ||
LongDoubleWidth = SaveLongDoubleWidth; | ||
LongDoubleAlign = SaveLongDoubleAlign; | ||
// For certain builtin types support on the host target, claim they are | ||
// supported 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 reject 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. This | ||
// 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; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these defined on both the host and device? I remember having a quite annoying time with these macros because HIP was defining stuff like
__AMDGCN_WAVEFRONT_SIZE
on the host.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
__AMDGCN_WAVEFRONT_SIZE
is a pretty terrible error, which should never have been defined on host (not in the least because it's non-uniform across targets). These do (should) end up defined on host too, but they are harmless because they are uniform i.e. all potential consumers ofspirv64-amd-amdhsa
are__AMD__
,__AMDGPU__
and__AMDGCN__
. They're mostly a necessary nuisance for getting library code to work.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've always thought defining those for both targets was obtuse, since those should act like architecture macros, i.e. (X86). But considering this is how it's done already, I suppose it's a necessary evil.