Skip to content

Panic-free ops via masking: {div,rem}_or #202

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

Open
Ben-Lichtman opened this issue Nov 26, 2021 · 6 comments
Open

Panic-free ops via masking: {div,rem}_or #202

Ben-Lichtman opened this issue Nov 26, 2021 · 6 comments
Labels
C-feature-request Category: a feature request, i.e. not implemented / a PR

Comments

@Ben-Lichtman
Copy link

Ben-Lichtman commented Nov 26, 2021

Hi, I was wondering if this team is considering the addition of masking arbitrary operations rather than just the gather select?

This is something already available in AVX512 through the kmask registers, though would probably require emulation on other platforms, but it seems like a very useful thing to have if at all possible.

One of the more awesome use cases I've seen for this is with vectorised emulation: https://gamozolabs.github.io/fuzzing/2018/10/14/vectorized_emulation.html which makes heavy use of masking to run / fuzz 8 virtual machines in parallel per core per thread.

@Ben-Lichtman Ben-Lichtman added the C-feature-request Category: a feature request, i.e. not implemented / a PR label Nov 26, 2021
@calebzulawski
Copy link
Member

The recommended way to do this is to simply perform the operation and mask as desired--when producing the asm, the backend will recognize that the two operations can be performed with a single instruction.

@Ben-Lichtman
Copy link
Author

Ben-Lichtman commented Nov 26, 2021

Ah, I see. That's reasonable then - something like

let a = ...;
let b = ...;
let mask = ...;

let operated = operate(a, b);

mask.select(operated, a)

@programmerjake
Copy link
Member

programmerjake commented Nov 26, 2021

this could still be reopened, cuz many operations still need masked versions, such as masked integer division, masked shift, etc.

basically everything that could panic or cause UB or has other side-effects that can't be masked just by ignoring lanes in the result.

@Ben-Lichtman Ben-Lichtman reopened this Nov 26, 2021
@workingjubilee workingjubilee changed the title Arbitrary operation masking Panic-free div/rem via masking Nov 26, 2021
@workingjubilee workingjubilee changed the title Panic-free div/rem via masking Panic-free ops via masking: {div,rem}_or Nov 26, 2021
@workingjubilee
Copy link
Member

workingjubilee commented Nov 26, 2021

re: shifts, I believe we should simply default our SIMD shift to the "wrapping" semantic the same way we default other operations to wrapping, also see rust-lang/rust#91237

I would be surprised if shl_or yielded better perf than wrapping_shl. The wrap should if anything help a compiler to simply serialize the RHS operand into an immediate operand, which would dominate perf next to dynamic operands on most arches.
If shl_or did tend to offer better perf, I would be sooner to consider shl_unchecked as a first step.

@workingjubilee
Copy link
Member

This is a duplicate of #118,
but I am arbitrarily closing that one instead because this has more actual content.

@workingjubilee
Copy link
Member

As of the sync getting merged, the shift ops on Simd types will wrap, like most of our ops do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: a feature request, i.e. not implemented / a PR
Projects
None yet
Development

No branches or pull requests

4 participants