Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@kfcripps
Copy link
Contributor

The following code will print warnings for each e in modifies in a non-deterministic order:

    for (auto p : *mi->substitution.getParametersInArgumentOrder()) {
        if (useTemporary.find(p) != useTemporary.end()) continue;
        auto arg = mi->substitution.lookup(p);
        if (typeMap->isCompileTimeConstant(arg->expression)) continue;
        for (auto e : modifies) {
            // Here we use just raw equality: equivalent but not equal expressions
            // should be compared.
            if (e != arg->expression && mayAlias(arg->expression, e, getContext())) {
                LOG3("Using temporary for " << dbp(mce) << " param " << dbp(p) << " aliasing"
                                            << dbp(e));
                if (p->hasOut())
                    warn(ErrorType::WARN_ORDERING,
                         "%1%: 'out' argument has fields in common with %2%", arg, e);
                useTemporary.emplace(p);
                break;
            }
        }
    }

@kfcripps kfcripps requested review from ChrisDodd and asl July 16, 2025 23:47
@kfcripps kfcripps enabled auto-merge July 17, 2025 00:05
@ChrisDodd
Copy link
Contributor

The following code will print warnings for each e in modifies in a non-deterministic order:

using an ordered_set for modifies as well should fix that?

@kfcripps kfcripps disabled auto-merge July 17, 2025 00:18
@kfcripps
Copy link
Contributor Author

@ChrisDodd That would ensure that the modifies iteration order is identical to modifies insertion order. But modifies insertion order would still not be stable, right (as gwe.written insertion and iteration order would still not be identical)?

@kfcripps
Copy link
Contributor Author

Maybe I am misunderstanding the question

@ChrisDodd
Copy link
Contributor

@ChrisDodd That would ensure that the modifies iteration order is identical to modifies insertion order. But modifies insertion order would still not be stable, right (as gwe.written insertion and iteration order would still not be identical)?

modifies is built in order from substitution.getParametersInArgumentOrder, so should be deterministic (in order of the arguments to resolved method call).

@kfcripps
Copy link
Contributor Author

@ChrisDodd Isn't modifies built here, using iteration order of gwe.written?

modifies.insert(gwe.written.begin(), gwe.written.end());

@kfcripps
Copy link
Contributor Author

Are you thinking of useTemporary?

@ChrisDodd
Copy link
Contributor

@ChrisDodd Isn't modifies built here, using iteration order of gwe.written?

modifies.insert(gwe.written.begin(), gwe.written.end());

So I guess written needs to be an ordered_set as well.

@fruffy fruffy added the core Topics concerning the core segments of the compiler (frontend, midend, parser) label Jul 17, 2025
@kfcripps kfcripps added this pull request to the merge queue Jul 17, 2025
Merged via the queue into p4lang:main with commit 19c7641 Jul 17, 2025
22 checks passed
@kfcripps kfcripps deleted the modifies-deterministic branch July 17, 2025 04:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Topics concerning the core segments of the compiler (frontend, midend, parser)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants