CMake build can compile peepopt.cc against incomplete generated peepopt_pm.h

[muditbhargava66]

CMake build fails because generated peepopt_pm.h is missing run_shiftpow2()

Summary

When building Yosys from the main branch with CMake, the build can fail during compilation of passes/opt/peepopt.cc because the generated passes/opt/peepopt_pm.h does not contain the run_shiftpow2() method expected by peepopt.cc.

The source tree contains peepopt_shiftpow2.pmg, and CMakeLists.txt references it, but the initially generated peepopt_pm.h did not include the corresponding generated pattern matcher.

The issue was resolved by explicitly rebuilding the yosys_peepopt target, which regenerated the pattern matcher header before compiling peepopt.cc.

Environment

• OS: Ubuntu 22.04 LTS
• Architecture: x86_64
• GCC: 13.4.0
• G++: 13.4.0
• CMake: 4.4.2
• Python: 3.13.15
• FLEX: 2.6.4
• BISON: 3.8.2
• GoogleTest: 1.11.0
• Yosys commit: fd6367405
• Yosys version reported by CMake: 0.68+46

Repository state

The repository was on:

fd6367405 (HEAD -> main) Merge pull request #6077 from YosysHQ/lofty/abc-refactor-8

Tracked source files had no modifications:

git diff --stat

returned no output.

The required submodules were initialized successfully with:

git submodule sync --recursive
git submodule update --init --recursive

including ABC and the other Yosys submodules.

Reproduction

The build was configured with:

cmake .. \
  -DCMAKE_C_COMPILER=gcc-13 \
  -DCMAKE_CXX_COMPILER=g++-13 \
  -DCMAKE_BUILD_TYPE=Release

CMake configuration completed successfully:

-- Configuring done
-- Generating done
-- Build files have been written to: /home/mudit/EDA_Tools/yosys/build

A normal build then progressed to approximately 82% before failing:

cmake --build . -j1

The failure was:

/home/mudit/EDA_Tools/yosys/passes/opt/peepopt.cc:124:44:
error: ‘struct {anonymous}::peepopt_pm’ has no member named ‘run_shiftpow2’;
did you mean ‘run_shiftadd’?

  124 |                                         pm.run_shiftpow2();
      |                                            ^~~~~~~~~~~~~~
      |                                            run_shiftadd

gmake[2]: *** [passes/opt/CMakeFiles/yosys_peepopt.dir/build.make:90:
passes/opt/CMakeFiles/yosys_peepopt.dir/peepopt.cc.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:7902:
passes/opt/CMakeFiles/yosys_peepopt.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Relevant source state

peepopt.cc contains:

pm.run_shiftadd();
pm.run_shiftpow2();

and the source tree contains:

passes/opt/peepopt_shiftadd.pmg
passes/opt/peepopt_shiftpow2.pmg

passes/opt/CMakeLists.txt also references both pattern files.

However, the generated passes/opt/peepopt_pm.h contained generated code for:

peepopt_shiftmul_right.pmg
peepopt_shiftmul_left.pmg
peepopt_shiftadd.pmg
peepopt_muldiv.pmg
peepopt_muldiv_c.pmg
peepopt_formal_clockgateff.pmg

but did not contain:

peepopt_shiftpow2.pmg

Consequently, it provided:

run_shiftadd()
run_shiftmul_left()
run_shiftmul_right()

but no:

run_shiftpow2()

Workaround / observed resolution

Removing the generated header and stale object files:

rm -f passes/opt/peepopt_pm.h
rm -f passes/opt/peepopt.o
rm -f passes/opt/peepopt.d

followed by a clean CMake configuration did not immediately regenerate the header during the configuration step, which is expected.

However, explicitly building the affected target:

cmake --build . --target yosys_peepopt -j1

produced:

Compiling pattern matcher passes/opt/peepopt_pm.h
Building CXX object passes/opt/CMakeFiles/yosys_peepopt.dir/peepopt.cc.o
Built target yosys_peepopt

After this targeted build, yosys_peepopt compiled successfully.

Expected behavior

A clean or normal CMake build should generate peepopt_pm.h with all pattern matcher sources required by peepopt.cc, including:

passes/opt/peepopt_shiftpow2.pmg

and therefore provide:

run_shiftpow2()

before compiling peepopt.cc.

Questions

Could the CMake dependency/generation rules for the PMGen-generated peepopt_pm.h be checked?

In particular:

1. Is peepopt_shiftpow2.pmg correctly represented as a dependency of the generated peepopt_pm.h target?
2. Is there a possibility for an incremental or parallel CMake build to compile peepopt.cc against an incomplete/stale generated peepopt_pm.h?
3. Should the generated header be generated as a single CMake target with all .pmg inputs as explicit dependencies?
4. Is the observed behavior expected after switching/updating the CMake build system, or is there a known recommended clean-build procedure?

Additional note

The ABC submodule initially also required synchronization:

git submodule sync --recursive
git submodule update --init --recursive

After that, ABC built successfully and was not involved in the final peepopt failure.

The failure therefore appears isolated to the generation/dependency handling of the PMGen output for peepopt.