[P4Smith] Initialize arrays using tuple expressions

[eyg1331]

When P4Smith's variable declaration generator was written, P4C didn't have an initializer for arrays (then header stacks). Support has since been added for initializing arrays using tuple expressions, and this PR allows P4Smith to generate such code (instead of leaving the arrays uninitialized).

[eyg1331]

Test failure seems to be some sort of compiler bug related to inlining. I'll take a closer look and open an issue once I've got a smaller reproducer.

Edit: Opened #5549

[kfcripps]

@eyg1331 Do you happen to know how the changes in this PR caused the program you shared in #5549 to start being generated? I was expecting the reproducer to contain a header stack initialization, but I don't see that.

[eyg1331]

@kfcripps As far as I can tell, Smith should have already been able to generate programs exhibiting this bug.

Because Smith uses a pseudorandom number generator to generate programs, small changes to how the IR is generated (in particular, the number of IR nodes generated -- this header stack initialization change causes Smith to generate new nodes for each array entry) can have a large impact on other parts of the program. Due to these perturbations, one of the seeds tested by the CI now exhibits the bug, which is why we caught it now.

The failing program does have a header stack initialization in it (otherwise the program wouldn't have changed), but it wasn't related to the bug so I removed it when minimizing the reproducer.

[kfcripps]

@eyg1331 Makes sense, thanks for the explanation!

[kfcripps]

@fruffy Is there currently any mechanism for easily disabling specific seeds in the P4Smith tests? It seems that the changes in this PR are just exposing an existing bug that is not actually caused by this PR. I'm wondering if we actually need to resolve #5549 first or if there is some other way to proceed.

[fruffy]

Because Smith uses a pseudorandom number generator to generate programs, small changes to how the IR is generated (in particular, the number of IR nodes generated -- this header stack initialization change causes Smith to generate new nodes for each array entry) can have a large impact on other parts of the program. Due to these perturbations, one of the seeds tested by the CI now exhibits the bug, which is why we caught it now.

Yes, that it is correct. There is a mechanism to adjust the likelihood of a particular generated node using the configurations here https://github.com/p4lang/p4c/blob/main/backends/p4tools/modules/smith/common/probabilities.h

But it is a bit finnicky. Would be nice to override this per command line.

@fruffy Is there currently any mechanism for easily disabling specific seeds in the P4Smith tests? It seems that the changes in this PR are just exposing an existing bug that is not actually caused by this PR. I'm wondering if we actually need to resolve #5549 first or if there is some other way to proceed.

iirc you should be able to add a known bug here https://github.com/p4lang/p4c/blob/main/backends/p4tools/modules/smith/scripts/compilation-test.sh#L7 and it continue generating.