For-loop and for-in-loop support for P4Smith

[zzmic]

This is a draft PR that aims to support for-loop and for-in-loop statement generations for P4Smith.

The approach I took to generate for-loop and for-in-loop statements is to intentionally replace auto *applyBlock = statementGenerator().genBlockStatement(false) with auto *applyBlock = new IR::BlockStatement(statOrDecls), where statOrDecls contains the generated for-loop and for-in-loop statements (that are pushed into statOrDecls before constructing the block statement) in backends/p4tools/modules/smith/targets/generic/target.cpp (https://github.com/zzmic/p4c/blame/8deba9128cd8ba9ce035909824e96e9c8cad0b3c/backends/p4tools/modules/smith/targets/generic/target.cpp#L114-L125). An issue with my current implementation is that although the for-loops and for-in-loops contain block statements, the block statements do not explicitly interact with the loop-control variables.

Currently, an abundant amount of TODOs (labeled as TODO(zzmic)s) is in several files under the backends/p4tools/modules/smith directory. Most are opinion-based questions that consider what standards should be adopted for each case, such as what the upper bounds of the for-loop/for-in-loop condition should be.

The time I tested the build based on the changes I've made (make check -j$(nproc)), it failed 512 cases, comprising 10% of the overall test cases. Most failing cases were located at testgen-p4c-bmv2-ptf with additional bmv2-ptf/testdata/p4_16_samples/ternary2-bmv2.p4 (Timeout) and smith-compile-core (Failed).

I've attached the (abridged) testing output (which includes the indications of all the failing tests), a sample P4Smith-generated program (with for-loop and for-in-loop statements), and the specific testing output of the case smith-compile-core (that I believe my changes directly account for the failure) to this draft PR.

failure_on_smith-compile-core.txt
make_check_abridged_output.txt
sample_p4smith_gen_prog_with_for_and_for_in_loops.txt

[zzmic]

std::string generateLoopControlVariable() {
    // Generate a random string of length 1 (i.e., a single character variable name,
    // such as i, j, k, etc.).
    const std::string lowerCaseAlphabet = "abcdefghijklmnopqrstuvwxyz";
    const char randomChar = lowerCaseAlphabet[Utils::getRandInt(lowerCaseAlphabet.size() - 1)];
    return std::string(1, randomChar);
}

I know this might a weird question, but I was wondering why the code snippet above could trigger the following error?
p4smith: /usr/include/boost/random/uniform_int_distribution.hpp:337: boost::random::uniform_int_distribution<IntType>::uniform_int_distribution(IntType, IntType) [with IntType = long int]: Assertion `min_arg <= max_arg' failed.

Because when I backtraced using GDB, it gives me the following, which is directly related to Utils::getRandInt(lowerCaseAlphabet.size() - 1).

... in P4Tools::Utils::getRandInt (min=1, max=0)
    at /home/zzmic/p4c/backends/p4tools/common/lib/util.cpp:67

The error happened when I executed smith-test-for-loop-support-build/p4smith --target generic --arch core smith-test-for-loop-support-build_gen_prog1.p4 --seed 30.

[fruffy]

I know this might a weird question, but I was wondering why the code snippet above could trigger the following error? ...

It looks like lowerCaseAlphabet is empty. What's the problem with getRandomString?

[fruffy]

Great that tests were added! Do they work?

One initial round of comments.

[zzmic]

I've been stumbling on how I could properly construct a P4Tools::P4Smith::StatementGenerator instance, which leads me to the obstacle of feeding a proper SmithTarget as the argument of the constructor (of P4Tools::P4Smith::StatementGenerator).

[fruffy]

I've been stumbling on how I could properly construct a P4Tools::P4Smith::StatementGenerator instance, which leads me to the obstacle of feeding a proper SmithTarget as the argument of the constructor (of P4Tools::P4Smith::StatementGenerator).

The first problem is that you are trying to build these in the top-level gtest directory. You need to put this in the smith-local test directory. Take a look at the testgen code to see how local gtests are instantiated.

[fruffy]

Almost there! This is great progress.

[fruffy]

Great! We can merge this version now.