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

Compiler Bug: Overwriting definitions at <MethodCallExpression>(22038)//<MethodCallExpression>(22017)//<BoolLiteral>(1718) #4507

Closed
kfcripps opened this issue Mar 6, 2024 · 5 comments · Fixed by #4797
Assignees
Labels
bug This behavior is unintended and should be fixed. core Topics concerning the core segments of the compiler (frontend, midend, parser) regression Code that previously compiled correctly either no longer compiles or produces invalid results.

Comments

@kfcripps
Copy link
Contributor

kfcripps commented Mar 6, 2024

Compiling the following P4 code:

extern void __e(in bit<28> arg);
extern void __e2(in bit<28> arg);

control C() {
    action bar(bool a, bool b) {
        bit<28> x; bit<28> y;
        if (a) {
            if (b) {
                __e(x);
            }
        } else {
            if (b) {
                __e2(y);
            }
        }
    }

    action foo() {
        bar(true, false);
    }

    table t {
        actions = { foo; }
        default_action = foo;
    }

    apply {
        t.apply();
    }
}

control proto();
package top(proto p);

top(C()) main;

results in:

In file: ... frontends/p4/def_use.h:456
Compiler Bug: Overwriting definitions at <MethodCallExpression>(22038)//<MethodCallExpression>(22017)//<BoolLiteral>(1718)

This bug has been introduced somewhere in between 812722f and 0685e1a.

@kfcripps kfcripps added bug This behavior is unintended and should be fixed. core Topics concerning the core segments of the compiler (frontend, midend, parser) labels Mar 6, 2024
@kfcripps
Copy link
Contributor Author

kfcripps commented Mar 6, 2024

This was also introduced by e60cb8a. :)

@kfcripps
Copy link
Contributor Author

kfcripps commented Mar 6, 2024

Actions inlining transforms foo() to something like this:

    @name("foo") action foo_0() {
        {
            @name("x") bit<28> x_0;
            @name("y") bit<28> y_0;
            if (true) {
                if (false) {
                    __e(x_0);
                }
            } else if (false) {
                __e2(y_0);
            }
        }
    }

The problem is similar to #4500.

The condition for both "if (false)" IR::IfStatements point to the same IR::BoolLiteral, which is not expected by SimplifyDefUse.

I was able to fix this with the following change to SubstituteParameters::postorder(IR::PathExpression *expr):

...
        auto value = subst->lookup(param)->expression->clone();
...

@kfcripps
Copy link
Contributor Author

kfcripps commented Mar 6, 2024

I was able to fix this with the following change to SubstituteParameters::postorder(IR::PathExpression *expr):

I am not sure if it would better to perform the cloning here or in ActionsInliner::preorder(IR::MethodCallStatement *statement) instead.

@kfcripps
Copy link
Contributor Author

kfcripps commented Mar 7, 2024

Here is another case, which hits the same Compiler bug, but is not fixed by my change described above:

extern void __e(in bit<28> arg);
extern void __e2(in bit<28> arg);

control C() {
    action bar(bool a, bool b) {
        bit<28> x; bit<28> y;
        if (a) {
            if (b) {
                __e(x);
            }
        } else {
            if (b) {
                __e2(y);
            }
        }
    }

    action baz() {
        bar(true, false);
    }

    action foo() {
        baz();
        baz();
    }

    table t {
        actions = { foo; }
        default_action = foo;
    }

    apply {
        t.apply();
    }
}

control proto();
package top(proto p);

top(C()) main;

@kfcripps
Copy link
Contributor Author

kfcripps commented Mar 7, 2024

or by inserting a pass that converts DAGs into trees before the def-use analysis.

This is starting to sound like the best solution..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This behavior is unintended and should be fixed. core Topics concerning the core segments of the compiler (frontend, midend, parser) regression Code that previously compiled correctly either no longer compiles or produces invalid results.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants