Lut4 by default sounds great, but please make the lut width configurable on the yosys optimizer sub-pipeline via pass option. Maybe it makes sense to just extend the mode pass option to split LUT into LUT3 and LUT4?

IIUC if we can limit the yosys optimizer pipeline to generate luts of a given size by configuration, then the rest of the pipeline doesn't need any special configuration and can just lower whatever luts it sees/supports at that stage. I.e., you don't need to touch the jaxite emitter and just let it fail on lut4, and secret-to-cggi can have both lut3 and lut4 patterns added without conflict.

I'm not too worried about having stuff in HEIR that jaxite_bool doesn't support (though adding support in jaxite_bool should be easy). But I know there are other groups (e.g., Cornami) that use the CGGI pipeline and may have limited support for certain LUT sizes.

Also, a long time ago when I was working on lut support in the yosys optimizer, I did some tests to see what was the best tradeoff of lut size vs runtime, and I recall lut5/lut6 being a net negative because you needed too large crypto parameters to support them, and the incremental reduction in circuit size didn't outweigh the added cost of the PBS. But lut3/lut4 were basically the same: lut4 took longer per PBS, but had a smaller circuit, and for the circuits I tried the runtime was similar.

At the time, my tfhe-rs CPU experiments put 3-bit PBS at 15.8ms, up to lut6 at 145ms, while circuit size reduction looked like this (for one example circuit), so 10x runtime for < 0.5x circuit reduction was pretty bad. I don't seem to have the exact lut4 numbers recorded from that experiment, though.

Ooh, very cool to see the past research! Is just thought about the ability to run on FPGAs, and would be a 'nice to have' as an appendix somewhere to write about the FPGA performance of the current CGGI pipelines (and mostly to show how much improvement we can do in the future).