https://github.com/bogner approved this pull request.
It's a bit unfortunate that we need so many HLSL specific
ImplicitConversionKinds, but I do think that the logic is easier to follow this
way so it's probably the right thing to do.
https://github.com/llvm/llvm-project/pull/96011
__
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/96011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
> Updated the description. In my tests, there are at least 5 copies of this
> file in the overall build output directory:
>
> ```
> //Debug/share/clang-doc
> //Release/share/clang-doc
> //MinSizeRel/share/clang-doc
> //RelWithDebInfo/share/clang-doc
> //share/clang-doc
> ```
>
>
bogner wrote:
This test fails on multi-config cmake generators (`cmake -G 'Visual Studio`
etc), exposing an existing bug in clang-doc. Since binaries end up under a
subdirectory like `build/Release/bin` but the default json and such end up in
`build/share/clang-doc`, running `clang-doc` from t
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/97505
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner requested changes to this pull request.
I don't think this is the right fix. The Release/Debug directories only exist
in the build tree, so this is incurring an unnecessary cost in an installed
clang-doc. Further, this won't work for configs like RelWithDebInfo.
Proba
https://github.com/bogner approved this pull request.
We may need to revisit the whole `ForwardedArguments` thing in general, as
there are a few funny things going on looking at the `-cc1` options coming out
of dxc - for example, before this change `-S` actually shows up twice sometimes.
In an
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/96823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -924,6 +939,23 @@ static bool checkExportedDeclContext(Sema &S, DeclContext
*DC,
/// Check that it's valid to export \p D.
static bool checkExportedDecl(Sema &S, Decl *D, SourceLocation BlockStart) {
+ // HLSL: export declaration is valid only on functions
+ if (S.getLan
@@ -924,6 +939,23 @@ static bool checkExportedDeclContext(Sema &S, DeclContext
*DC,
/// Check that it's valid to export \p D.
static bool checkExportedDecl(Sema &S, Decl *D, SourceLocation BlockStart) {
+ // HLSL: export declaration is valid only on functions
+ if (S.getLan
@@ -851,6 +851,21 @@ Decl *Sema::ActOnStartExportDecl(Scope *S, SourceLocation
ExportLoc,
CurContext->addDecl(D);
PushDeclContext(S, D);
+ if (getLangOpts().HLSL) {
+// exported functions cannot be in an unnamed namespace
+for (const DeclContext *DC = CurContext;
https://github.com/bogner commented:
Please add some tests that show that we still handle bitfields correctly in
HLSL with this change.
https://github.com/llvm/llvm-project/pull/96346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -o - %s
-verify
+
+// previously, this test would result in an error shown below on the line that
+// declares variable a in struct Eg9:
+// error: use of undeclared identifier
+// 'SV_Dispat
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -o - %s
-verify
+
+// previously, this test would result in an error shown below on the line that
+// declares variable a in struct Eg9:
+// error: use of undeclared identifier
+// 'SV_Dispat
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/96346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner closed https://github.com/llvm/llvm-project/pull/96335
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner created
https://github.com/llvm/llvm-project/pull/96335
The resource class isn't HLSL specific, and we'll need to use it in the DirectX
backend as well.
I've also removed the "invalid" enum value since it isn't needed or used, which
necessitates fixing up the clang a
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/95999
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/95489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner closed https://github.com/llvm/llvm-project/pull/95155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4,9 +4,8 @@
void test() {
// CHECK: VarDecl {{.*}} used f3 'vector':'float
__attribute__((ext_vector_type(3)))' cinit
- // CHECK-NEXt: ImplicitCastExpr {{.*}} 'vector':'float
__attribute__((ext_vector_type(3)))'
- // CHECK-NEXt: ImplicitCastExpr {{.*}} 'float'
-
@@ -4,9 +4,8 @@
void test() {
// CHECK: VarDecl {{.*}} used f3 'vector':'float
__attribute__((ext_vector_type(3)))' cinit
- // CHECK-NEXt: ImplicitCastExpr {{.*}} 'vector':'float
__attribute__((ext_vector_type(3)))'
- // CHECK-NEXt: ImplicitCastExpr {{.*}} 'float'
-
https://github.com/bogner created
https://github.com/llvm/llvm-project/pull/95155
These are the HLSL specific fixes from #93193. Thanks @klensy!
>From ef5fbb85ba550c1baefc6357e118f339e6d7d5bd Mon Sep 17 00:00:00 2001
From: Justin Bogner
Date: Tue, 11 Jun 2024 10:48:30 -0700
Subject: [PATCH] [H
@@ -834,34 +841,41 @@ void
DiagnoseUnguardedAvailability::DiagnoseDeclAvailability(
OffendingDecl))
return;
-// We would like to emit the diagnostic even if -Wunguarded-availability is
-// not specified for deployment
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/93879
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -114,18 +114,21 @@ Parser::ParseStatementOrDeclaration(StmtVector &Stmts,
// here because we don't want to allow arbitrary orderings.
ParsedAttributes CXX11Attrs(AttrFactory);
MaybeParseCXX11Attributes(CXX11Attrs, /*MightBeObjCMessageSend*/ true);
- ParsedAttributes G
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/93879
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -834,34 +829,55 @@ void
DiagnoseUnguardedAvailability::DiagnoseDeclAvailability(
OffendingDecl))
return;
-// We would like to emit the diagnostic even if -Wunguarded-availability is
-// not specified for deployment
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/93847
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
> > I don't really understand the rationale for this, and it's kind of
> > annoying. Most of the compiler's flags behave in the "last one wins"
> > fashion (such as `-O2` and `-O0`) and it's always been convenient to add
> > the flag you want at the end. Why treat action flags an
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/93314
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
I don't really understand the rationale for this, and it's kind of annoying.
Most of the compiler's flags behave in the "last one wins" fashion (such as
`-O2` and `-O0`) and it's always been convenient to add the flag you want at
the end. Why treat action flags any differently? A
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/92793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8,6 +8,12 @@ set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD "DirectX;SPIRV" CACHE
STRING "")
# HLSL support is currently limted to clang, eventually it will expand to
# clang-tools-extra too.
-set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(LLVM_ENABLE_PROJECTS "clang;clan
https://github.com/bogner approved this pull request.
Including clang-tools-extra makes sense to me. Setting up the distribution may
not be as universal but it seems fine too as a default in this cache file.
LGTM
https://github.com/llvm/llvm-project/pull/92011
_
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/92011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?= ,
Nathan =?utf-8?q?Gau=C3=ABr?=
Message-ID:
In-Reply-To:
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/88918
https://github.com/bogner closed https://github.com/llvm/llvm-project/pull/91500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/91474
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/91407
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
> > It would be nice to mention in the description what the sanitizer fix was
> > compared to the original PR.
>
> Thanks! The fix to address ASAN failure is in commit
> [8522e36](https://github.com/llvm/llvm-project/commit/8522e3609869d72b7b457a4752149a802be4662d)
> of this PR.
bogner wrote:
When reapplying a change that was reverted, please include enough information
in the description so that it can be understood without having to dig up the
old change. Something like:
> [HLSL] reenable add packoffset in AST
>
> This reapplies c5509fedc575 "[HLSL] Support packoffse
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -744,7 +744,7 @@ void codegen::setFunctionAttributes(StringRef CPU,
StringRef Features,
Expected>
codegen::createTargetMachineForTriple(StringRef TargetTriple,
CodeGenOptLevel OptLevel) {
- Triple TheTriple(TargetTriple);
+ Triple The
https://github.com/bogner approved this pull request.
Other than [my comment
here](https://github.com/llvm/llvm-project/pull/90809/files#r1589771652) about
what to do in getArchName this looks reasonable.
The string handling in `normalize` feels a bit unwieldy, but I don't have any
obvious th
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/90809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -115,6 +115,30 @@ StringRef Triple::getArchName(ArchType Kind, SubArchType
SubArch) {
if (SubArch == AArch64SubArch_arm64e)
return "arm64e";
break;
+ case Triple::dxil:
+switch (SubArch) {
+case Triple::NoSubArch:
+case Triple::DXILSubArch_v1_0:
+
@@ -744,7 +744,7 @@ void codegen::setFunctionAttributes(StringRef CPU,
StringRef Features,
Expected>
codegen::createTargetMachineForTriple(StringRef TargetTriple,
CodeGenOptLevel OptLevel) {
- Triple TheTriple(TargetTriple);
+ Triple The
@@ -1200,6 +1224,27 @@ std::string Triple::normalize(StringRef Str) {
}
}
+ // Normalize DXIL triple if it does not include DXIL version number.
+ // Determine DXIL version number using the minor version number of Shader
+ // Model version specified in target triple,
@@ -630,7 +630,7 @@ extern "C" int optMain(
}
}
- Triple ModuleTriple(M->getTargetTriple());
+ Triple ModuleTriple(Triple::normalize(M->getTargetTriple()));
bogner wrote:
Similarly to my concern about updating `createTargetMachineForTriple`, I don't
@@ -4675,7 +4676,7 @@ bool CompilerInvocation::CreateFromArgsImpl(
// FIXME: We shouldn't have to pass the DashX option around here
InputKind DashX = Res.getFrontendOpts().DashX;
ParseTargetArgs(Res.getTargetOpts(), Args, Diags);
- llvm::Triple T(Res.getTargetOpts().Trip
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/90694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -0,0 +1,799 @@
+==
+DXIL Resource Handling
+==
+
+.. contents::
+ :local:
+
+.. toctree::
+ :hidden:
+
+Introduction
+
+
+Resources in DXIL are represented via ``TargetExtType`` in LLVM IR and
+eventually lowered by the Di
@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(NewAttr);
}
+static void DiagnoseHLSLResourceRegType(Sema &S, SourceLocation &ArgLoc,
+Decl *D, StringRef &Slot) {
+ // Sa
@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(NewAttr);
}
+static void DiagnoseHLSLResourceRegType(Sema &S, SourceLocation &ArgLoc,
+Decl *D, StringRef &Slot) {
+ // Sa
@@ -2,39 +2,45 @@
// Supported targets
//
-// RUN: %clang -target dxil--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 |
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-pixel %s -S -o /dev/null
2>&1 | FileCheck --check-prefix=CHECK-V
@@ -115,6 +115,30 @@ StringRef Triple::getArchName(ArchType Kind, SubArchType
SubArch) {
if (SubArch == AArch64SubArch_arm64e)
return "arm64e";
break;
+ case Triple::dxil:
+switch (SubArch) {
+case Triple::DXILSubArch_v1_0:
+ return "dxilv1.0";
+
@@ -2,39 +2,45 @@
// Supported targets
//
-// RUN: %clang -target dxil--shadermodel6.2-pixel %s -S -o /dev/null 2>&1 |
FileCheck --check-prefix=CHECK-VALID %s
-// RUN: %clang -target dxil-unknown-shadermodel6.2-pixel %s -S -o /dev/null
2>&1 | FileCheck --check-prefix=CHECK-V
@@ -98,9 +103,47 @@ std::optional tryParseProfile(StringRef
Profile) {
else if (llvm::getAsUnsignedInteger(Parts[2], 0, Minor))
return std::nullopt;
- // dxil-unknown-shadermodel-hull
+ // Determine DXIL version number using the minor version number of Shader
+ // Mo
@@ -1171,18 +1181,27 @@ TEST(TripleTest, Normalization) {
Triple::getOSTypeName(FirstOSType),
Triple::getEnvironmentTypeName(FirstEnvType)};
for (int Arch = FirstArchType; Arch <= Triple::LastArchType; ++Arch) {
-StringR
https://github.com/bogner requested changes to this pull request.
There's a lot of churn here so I'm not 100% sure I saw all of the real changes,
but I think I got them all. It might be nice to move the NFC parts into their
own commit (if we actually need them, see my other comments).
I don't
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/89823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -25,6 +25,7 @@ enum class ResourceClass : uint8_t {
SRV = 0,
UAV,
CBuffer,
+ TBuffer,
bogner wrote:
I hadn't noticed this. Xiang's right, this isn't correct. See
`CGHLSLRuntime::finishCodeGen` - a tbuffer is annotated with a resource class
of `SRV`
@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o -
-fsyntax-only %s -verify
+
+// the below will cause an llvm unreachable, because RWBuffers don't have
resource attributes yet
+// expected-error@+1 {{invalid register name prefix 'b' for re
@@ -7334,6 +7334,100 @@ static void handleHLSLShaderAttr(Sema &S, Decl *D,
const ParsedAttr &AL) {
D->addAttr(NewAttr);
}
+static void DiagnoseHLSLResourceRegType(Sema &S, SourceLocation &ArgLoc,
+Decl *D, StringRef &Slot) {
+ // S
@@ -7334,6 +7334,81 @@ static void handleHLSLShaderAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(NewAttr);
}
+static void DiagnoseHLSLResourceRegType(Sema &S, SourceLocation &ArgLoc,
+Decl *D, StringRef &Slot) {
+ // Sa
@@ -45,7 +45,7 @@ void foo2() {
extern RWBuffer U2 : register(u5);
}
// FIXME: expect-error once fix
https://github.com/llvm/llvm-project/issues/57886.
-float b : register(u0, space1);
+// float b : register(u0, space1) {}
bogner wrote:
Shouldn't we be addi
@@ -478,33 +478,35 @@ void HLSLExternalSemaSource::defineTrivialHLSLTypes() {
/// Set up common members and attributes for buffer types
static BuiltinTypeDeclBuilder setupBufferType(CXXRecordDecl *Decl, Sema &S,
- ResourceClass RC,
@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o -
-fsyntax-only %s -verify
+
+// the below will cause an llvm unreachable, because RWBuffers don't have
resource attributes yet
+// NOT YET IMPLEMENTED : {{invalid register name prefix 'b' for
@@ -7334,6 +7334,81 @@ static void handleHLSLShaderAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
D->addAttr(NewAttr);
}
+static void DiagnoseHLSLResourceRegType(Sema &S, SourceLocation &ArgLoc,
+Decl *D, StringRef &Slot) {
+ // Sa
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?=
Message-ID:
In-Reply-To:
@@ -3101,3 +3130,68 @@ CodeGenFunction::GenerateCapturedStmtFunction(const
CapturedStmt &S) {
return F;
}
+
+namespace {
+// Returns the first convergence entry/loop/anchor instruction found in
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?=
Message-ID:
In-Reply-To:
@@ -3101,3 +3130,68 @@ CodeGenFunction::GenerateCapturedStmtFunction(const
CapturedStmt &S) {
return F;
}
+
+namespace {
+// Returns the first convergence entry/loop/anchor instruction found in
https://github.com/bogner approved this pull request.
Yeah, this is definitely better.
https://github.com/llvm/llvm-project/pull/89130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
This feels complicated and not very scalable. I don't think we should be
implementing ad-hoc vtables via a map of function pointers.
It might be worth sketching out a design for an API that can handle the various
cases we're running into here. We need to be able to handle (1) ope
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/89309
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner closed https://github.com/llvm/llvm-project/pull/88939
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
> a) Thanks!; b) apologies for the noise; c) this was actually done on purpose,
> I actively eschewed changing Logical SPIRV because it wasn't actually clear
> to me if in the long run it'd have the same AS map / would use numerical 1
> for globals. If Logical SPIRV is going to g
bogner wrote:
Looks like this missed a spot, causing the .hlsl to spir-v tests to fail. I've
put up a fix in #88939
https://github.com/llvm/llvm-project/pull/88455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/88354
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/87346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
@@ -119,8 +119,10 @@ struct BuiltinTypeDeclBuilder {
ResourceKind RK, bool IsROV) {
if (Record->isCompleteDefinition())
return *this;
-Record->addAttr(HLSLResourceAttr::CreateImplicit(Record->getASTContext(),
-
@@ -7333,12 +7333,12 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
} else {
Slot = Str;
}
-
+ QualType Ty = ((clang::ValueDecl *)D)->getType();
bogner wrote:
LLVM avoids C-style casting. This would normally be spelled `QualType QT =
@@ -482,15 +484,18 @@ static BuiltinTypeDeclBuilder
setupBufferType(CXXRecordDecl *Decl, Sema &S,
bool IsROV) {
return BuiltinTypeDeclBuilder(Decl)
.addHandleMember()
- .addDefaultHandleConstructor(S, RC)
- .annot
@@ -7367,8 +7367,72 @@ static void handleHLSLResourceBindingAttr(Sema &S, Decl
*D,
return;
}
- // FIXME: check reg type match decl. Issue
- // https://github.com/llvm/llvm-project/issues/57886.
+ VarDecl *VD = dyn_cast(D);
+ HLSLBufferDecl *BD = dyn_cast(D);
+
+ if
bogner wrote:
The `GENERATE_HLSL_INTRINSIC_FUNCTION` abstraction parts of this look fairly
reasonable, but do we really want/need dx and spirv intrinsics for the "all"
function? This is trivial to generate pretty generic IR for and I don't really
see the value of maintaining that the user wrot
@@ -4117,14 +4117,17 @@ ExprResult Sema::ActOnNumericConstant(const Token &Tok,
Scope *UDLScope) {
} else if (Literal.isFloatingLiteral()) {
QualType Ty;
if (Literal.isHalf){
- if (getOpenCLOptions().isAvailableOption("cl_khr_fp16", getLangOpts()))
+ if (ge
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/87270
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bogner edited https://github.com/llvm/llvm-project/pull/87270
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bogner wrote:
I have some misgivings about abusing the target intrinsic infrastructure like
this to create "target" intrinsics for a non-existent target. IMO this is
morally equivalent to just putting all of these intrinsics as generic llvm
intrinsics (`llvm.thread_id` or `llvm.all`), just wit
201 - 300 of 576 matches
Mail list logo
