Skip to content

Conversation

tlively
Copy link
Member

@tlively tlively commented Jun 26, 2024

Give the type fuzzer the ability to generate shared heap types when the
shared-everything feature is enabled. It correctly ensures that shared
structs and arrays cannot reference unshared heap types, but that
unshared heap types can reference any heap type.

Update the main fuzzer so that for the time being it never uses the
shared-everything feature when generating additional heap types, so it
never generates shared types. We can lift this restriction once the main
fuzzer has been updated to properly handle shared types.

As a drive-by, fix some logic for subtracting feature sets from each
other that is used in this commit.

Give the type fuzzer the ability to generate shared heap types when the shared-everything feature is enabled. It correctly ensures that shared structs and arrays cannot reference unshared heap types, but that unshared heap types can reference any heap type. Update the main fuzzer so that for the time being it never uses the shared-everything feature when generating additional heap types, so it never generates shared types. We can lift this restriction once the main fuzzer has been updated to properly handle shared types. As a drive-by, fix some logic for subtracting feature sets from each other that is used in this commit.
@tlively tlively requested a review from kripken June 26, 2024 03:03
if (share == Shared) {
// We can only reference other shared types.
std::vector<Index> eligible;
for (Index i = 0, n = recGroupEnds[index]; i < n; ++i) {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
for (Index i = 0, n = recGroupEnds[index]; i < n; ++i) {
for (Index i = 0; i < recGroupEnds[index]; ++i) {

That was an optimization, I assume? I trust the compiler to LICM it, so it seems better to keep the code shorter.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think the compiler will be able to prove that the contents of recGroupEnds[index] will not be modified by the loop body, and this pattern is not too rare, so I think this code is reasonable as-is.

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough. I don't feel it's a critical line to optimize but sgtm.

@tlively tlively merged commit ff8095d into main Jun 26, 2024
@tlively tlively deleted the threads-fuzz-types branch June 26, 2024 18:19
@gkdn gkdn mentioned this pull request Aug 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants