Add preprocessor option to interpret translate_on/off pragmas

[povik]

For synthesis tools based on slang, add a preprocessor option to interpret pragmas like

    // pragma translate_off
    assert(...); // meant to be ignored in synthesis
    // pragma translate_on

Given the non-standard nature of the pragmas, make the exact regex a preprocessor option.

Related: povik/yosys-slang#28

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.76%. Comparing base (f6e3510) to head (19dd80a).
Report is 19 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1100   +/-   ##
=======================================
  Coverage   94.76%   94.76%           
=======================================
  Files         191      191           
  Lines       47743    47771   +28     
=======================================
+ Hits        45243    45271   +28     
  Misses       2500     2500           

Files with missing lines	Coverage Δ
include/slang/parsing/Preprocessor.h	100.00% <ø> (ø)
source/parsing/Preprocessor.cpp	100.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f6e3510...19dd80a. Read the comment docs.

[likeamahoney]

Is it assumed that these options can only be used from the API?

I think it would be useful to use them from the slang cli interface as well

[povik]

Right now I am setting these with a downstream patch to Driver.cpp. For yosys-slang I think we want it on by default, possibly with a cli option to change the regexes or disable it.

If we can agree on standard slang options for this (with yosys-slang having it on by default, vanilla slang having it off by default), that would be great

[povik]

If we can agree on standard slang options for this

By that I mean the cli of course

[MikePopoloski]

The Lexer already has an optional path for checking for pragma comments -- see Lexer::scanLineComment and scanProtectComment. Can this functionality be put there as well instead of adding a new branch in the preprocessor?

Also how necessary is the regex behavior? Can a substring match be used instead? I ask because std::regex is notoriously slow -- if full regex functionality is required we probably want to at least provide the option of pulling in a performant 3rd party regex lib.

[povik]

The Lexer already has an optional path for checking for pragma comments -- see Lexer::scanLineComment and scanProtectComment. Can this functionality be put there as well instead of adding a new branch in the preprocessor?

It can though I think we want to collect the full comment line before we try to match it against the user-provided list of pragmas -- both for the off pragma and the on pragma. On the other hand the protect stuff is matched verbatim. So the new functionality can be moved to the Lexer but I think it would involve a new branch there too.

Also how necessary is the regex behavior? Can a substring match be used instead? I ask because std::regex is notoriously slow -- if full regex functionality is required we probably want to at least provide the option of pulling in a performant 3rd party regex lib.

I don't think a simple substring match would cut it but if we write something simple which would bridge over any whitespacing differences in matching against the known pragma list then that would work. In any case rolling out custom matching sounds simpler than setting up the infrastructure for optional 3rd party regex libs.

[povik]

@MikePopoloski should I move the detection to the Lexer?

[MikePopoloski]

Yes, I think so. I'd like to keep all comment parsing isolated to that one branch if possible.

[udif]

If we're going for legacy, you also have // synopsys translate_off and // synopsys translate_on that had been traditionally supported by DC.

[povik]

The detection is configurable and accounts for those too. There's no set of pragmas which is hard-coded in the patch.

[MikePopoloski]

Going to close this out for now. Feel free to reopen if you modify the approach, or open an issue if you want me to look into it when I get some spare cycles.