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

wgsl-in, glsl-in: Short circuit || and && #2028

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

adeline-sparks
Copy link
Contributor

@adeline-sparks adeline-sparks commented Aug 15, 2022

Copy link
Collaborator

@JCapucho JCapucho left a comment

Choose a reason for hiding this comment

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

Disclaimer: only read the glsl code yet, so this might or might not apply to the wgsl frontend

There's an issue with your implementation, you're always branching on the left expression, this is true for LogicalAnd but not for LogicalOr, the latter must only execute the right hand side if it evaluates to false.

Also you seem to be creating the following pseudocode:

if (left) {
  local = right
} else {
  local = constant
}

you could instead do:

local = left
if (left) {
  local = right
}

@adeline-sparks
Copy link
Contributor Author

Looking at this again, I think it is translating things correctly. The tests show that for the && case, the RHS is evaluated in the accept branch of the if statement, while for the || it is evaluated in the reject branch.

I'll have a go at generating multiple assignments instead of single assignment. Would it be better to create a logical not and always leave the reject branch empty so that the generated code doesn't use an else in the || case?

@teoxoy
Copy link
Member

teoxoy commented Dec 2, 2022

Looking at this again, I think it is translating things correctly. The tests show that for the && case, the RHS is evaluated in the accept branch of the if statement, while for the || it is evaluated in the reject branch.

Tests seem correct indeed, but quite verbose (see below).

Would it be better to create a logical not and always leave the reject branch empty so that the generated code doesn't use an else in the || case?

I think so (as per @JCapucho's suggestion) because the extra assignments are redundant, we already know the var is true/false.

@cwfitzgerald
Copy link
Member

Hello, thank you for your PR against Naga!

As part of gfx-rs/wgpu#4231, we have moved development of Naga into the wgpu repository in the Naga subfolder. We have transferred all issues, but we are unable to automatically transfer PRs.

As such, please recreate your PR against the wgpu repository. We apologize for the inconvenience this causes, but will make contributing to both projects more streamlined going forward.

We are leaving PRs open, but once they are transferred, please close the original Naga PR.

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.

Naga front ends do not properly short-circuit && and ||
4 participants