Skip to content
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

Feature/initialize list side branch #6058

Open
wants to merge 48 commits into
base: master
Choose a base branch
from

Conversation

kaizhangNV
Copy link
Contributor

No description provided.

@kaizhangNV kaizhangNV marked this pull request as draft January 10, 2025 18:37
@kaizhangNV kaizhangNV added the pr: breaking change PRs with breaking changes label Jan 10, 2025
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 12 times, most recently from 282ad96 to 8be343e Compare January 16, 2025 04:51
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 6 times, most recently from 2f3c992 to 7c5a8e8 Compare January 17, 2025 05:16
@kaizhangNV kaizhangNV marked this pull request as ready for review January 17, 2025 16:57
Add cuda-host decoration for the synthesized constructor if there
is any usage of TorchTensor.
When creating invoke expression for ctor, we need to call
ResolveInvoke() to find us the best candidates, however
the existing lookup logic could find us the base constructor
for child struct, we should eliminate this case by providing
the LookupOptions::IgnoreInheritance to lookup, this requires
us to create a subcontext on SemanticsVisitor to indicate that
we only want to use this option on looking the constructor.

This change implements this.
Apply all the initializer list logic on core moduls structs as well.

Add special case handling for backwards-compatibility feature for HLSL
when type cast a literal zero to a 'struct'.
Instead of checking what is C-Style struct, we should check C-Style
type.

Proposal is not very clear about this. Will also update proposal.
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 5 times, most recently from 1788d3b to 55ea908 Compare January 24, 2025 01:20
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch from 55ea908 to 9194117 Compare January 24, 2025 01:30
source/slang/slang-check-overload.cpp Outdated Show resolved Hide resolved
source/slang/hlsl.meta.slang Show resolved Hide resolved
source/slang/slang-ast-expr.h Outdated Show resolved Hide resolved
@@ -28,6 +28,8 @@ static List<ConstructorDecl*> _getCtorList(
SemanticsVisitor* visitor,
StructDecl* structDecl,
ConstructorDecl** defaultCtorOut);
static Expr* constructDefaultInitExprForType(SemanticsVisitor* visitor, VarDeclBase* varDecl);
void addVisibilityModifier(ASTBuilder* builder, Decl* decl, DeclVisibility vis);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have access to ASTBuilder directly via this?

// We will defer the actual implementation of the constructor to the body visit, because
// we will have full information about each field in the struct during that stage.
void _synthesizeCtorSignature(StructDecl* structDecl);
bool _searchInitializableMembers(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming: collectInitializableMembers

@@ -331,6 +346,7 @@ struct SemanticsDeclBodyVisitor : public SemanticsDeclVisitorBase,
StructDecl* parent,
const bool getOnlyDefault)
{
this->parent = parent;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoid parameter names that collide with member names. can rename the parameter to inParent.

@@ -2241,7 +2310,7 @@ void SemanticsDeclBodyVisitor::checkVarDeclCommon(VarDeclBase* varDecl)
if (getOptionSet().hasOption(CompilerOptionName::ZeroInitialize) && !varDecl->initExpr &&
as<VarDecl>(varDecl))
{
varDecl->initExpr = constructDefaultInitExprForVar(this, varDecl);
varDecl->initExpr = constructDefaultInitExprForType(this, varDecl);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be done in a later PR, but we should remove zero init logic from the front-end.

@@ -1718,7 +1725,7 @@ public struct SlangDesc
public struct ShaderCacheDesc
{
// The root directory for the shader cache. If not set, shader cache is disabled.
public NativeString shaderCachePath;
public NativeString shaderCachePath = {0};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why this is needed. NativeString should be treated as a default-initializable type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NativeString has explicit constructor defined. So it's not a default-initializable type.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should provide a default ctor here.

@@ -1698,17 +1705,17 @@ public interface IDebugCallback

public struct SlangDesc
{
public NativeRef<slang::IGlobalSession> slangGlobalSession; // (optional) A slang global session object. If null will create automatically.
public NativeRef<slang::IGlobalSession> slangGlobalSession = {slang::IGlobalSession()}; // (optional) A slang global session object. If null will create automatically.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NativeRef also has explicit constructor defined.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should provide a default ctor for the type.

public ShaderModuleSourceType sourceType;
public void *sourceData;
public Size sourceDataSize;
public ShaderModuleSourceType sourceType = ShaderModuleSourceType::SlangSource;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it weird to force initialize everything in these descs, why do we need this?

@@ -17,7 +17,7 @@ struct Ray : IDifferentiable {
[numthreads(1, 1, 1)]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
Ray ray = Ray();
Ray ray = Ray(0, float3(0, 0, 0), float3(0, 0, 0));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the spec, since float and float3 are all default-initializable types, the synthesized ctor should contain default values for these parameters, so why can't we call Ray() here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to our new rule,

float and float3 won't be default-initializable types anymore, because they all have explicit ctor defined.
If we want to make them default-initializable type, we have to define default ctor for them.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this may require the same treatment as C-style types, in that the explicit ctor rule applies to user defined types, but for builtin vectors, scalars, matrices we still want to treat them as default initializable.

I am not sure about the consequences yet, so maybe we do this as a follow up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I recommend we should keep this as it, every time when we change the proposal, it could potential break things.

source/slang/slang-check-decl.cpp Show resolved Hide resolved
source/slang/slang-ast-decl.h Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
memberExpr->scope = scope;
memberExpr->loc = member->loc;
memberExpr->name = member->getName();
memberExpr->type = DeclRefType::create(getASTBuilder(), member->getDefaultDeclRef());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

member->getDefaultDeclRef() is a declref to the member and not to a type, it can't be used in DeclRefType::create() IIRC.

The declref you pass to DeclRefType::create() can only refer to a struct, enum, typedef or interface.

source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-expr.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-overload.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-overload.cpp Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: breaking change PRs with breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants