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

Allow local const declarations to have abstract types #7222

Merged
merged 1 commit into from
Mar 6, 2025

Conversation

jamienicol
Copy link
Contributor

@jamienicol jamienicol commented Feb 25, 2025

Connections
Second half of #6232 (and therefore follow up from #7055) - for local consts as opposed to global consts

Description
Just like global consts, local const declarations are allowed to have abstract types. This means we must avoid concretizing them when they are declared and instead can convert them to applicable type for each expression they are used in, during constant evaluation . This ensures no used expressions of abstract types will remain after constant evaluation, and we can then rely on the compact pass to remove the unused expressions and types.

The only hitch with that is that we always treat named expressions as used, for the purposes of compaction. This is mostly so that our snapshots tests are actually useful, as otherwise the majority of expressions would be stripped! We therefore avoid adding local constants of abstract types to the named expressions list in the first place. This ensures we don't end up with abstract types in the IR during validation. But it does mean that abstract local const declarations will not appear in the output - something to bear in mind when writing snasphot tests.

Testing
Added additinal cases to snapshot tests

Squash or Rebase?

Single commit - don't mind

Checklist

  • Run cargo fmt.
    - [ ] Run taplo format.
  • Run cargo clippy. If applicable, add:
    - [ ] --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • Add change to CHANGELOG.md. See simple instructions inside file.

@ErichDonGubler
Copy link
Member

Gonna proactively assign to @jimblandy, since he requested that this review be split out from #7055.

Comment on lines +1589 to +1595
// Only add constants of non-abstract types to the named expressions
// to prevent abstract types ending up in the IR.
let is_abstract = ctx.module.types[ty].inner.is_abstract(&ctx.module.types);
if !is_abstract {
ctx.named_expressions
.insert(init, (c.name.name.to_string(), c.name.span));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is another reason why we might not want const expr in named expr at all. #6207 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

That doesn't seem unreasonable to me.

…abstract types

Instead allow the const to be converted each time it is const
evaluated as part of another expression. This allows an abstract const
to be used as a different type depending on the context.

As a result, abstract types may now find their way in to the IR, which
we don't want. This occurs because the compact pass treats named
expressions as used, mostly so that our snapshot tests are more
useful, and therefore does not remove them. To prevent this, we avoid
adding abstract-typed local consts to the named expressions list. This
will have no functional effect on any shaders produced by the
backends, but some unused local const declarations will no longer be
present.
@jimblandy jimblandy force-pushed the abstract-local-consts branch from f615461 to cbb9f22 Compare March 3, 2025 16:48
Copy link
Member

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

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

Looks good to me!

@jimblandy jimblandy merged commit 7df6e47 into gfx-rs:trunk Mar 6, 2025
34 checks passed
@jamienicol jamienicol deleted the abstract-local-consts branch March 6, 2025 08:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants