Evaluate __builtin_ffs{,l,ll} over constants at compile time

[tautschnig]

GCC evaluates this built-in at compile time, and the Linux kernel
assumes this is the case.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[martin-cs]

Yes but...

1. Do we have any tests for what happens when it is not a compile-time constant?
2. Given that this has quite a few a few friends that need to be (partially, constant only, etc.) evaluated before / during type checking, is it time to start thinking about an abstraction / pass / organisation of these?

[codecov]

Codecov Report

Base: 77.87% // Head: 77.84% // Decreases project coverage by -0.03% ⚠️

Coverage data is based on head (9d072ba) compared to base (3034749).
Patch coverage: 91.07% of modified lines in pull request are covered.

❗ Current head 9d072ba differs from pull request most recent head e13e360. Consider uploading reports for the commit e13e360 to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5740      +/-   ##
===========================================
- Coverage    77.87%   77.84%   -0.04%     
===========================================
  Files         1576     1571       -5     
  Lines       181824   180544    -1280     
===========================================
- Hits        141598   140547    -1051     
+ Misses       40226    39997     -229     

Impacted Files	Coverage Δ
src/ansi-c/expr2c.cpp	67.30% <ø> (+0.12%)	⬆️
src/util/format_expr.cpp	86.89% <0.00%> (-0.47%)	⬇️
src/util/simplify_expr_class.h	90.47% <ø> (ø)
src/ansi-c/c_typecheck_expr.cpp	77.03% <72.72%> (+2.83%)	⬆️
src/solvers/flattening/boolbv.cpp	87.91% <100.00%> (+0.82%)	⬆️
src/solvers/smt2/smt2_conv.cpp	68.89% <100.00%> (+0.20%)	⬆️
src/util/bitvector_expr.cpp	65.57% <100.00%> (+7.01%)	⬆️
src/util/bitvector_expr.h	97.36% <100.00%> (+0.12%)	⬆️
src/util/simplify_expr.cpp	83.22% <100.00%> (-0.35%)	⬇️
src/crangler/ctokenit.h	0.00% <0.00%> (-83.34%)	⬇️
... and 199 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[tautschnig]

Yes but...

1. Do we have any tests for what happens when it is not a compile-time constant?

We do - the existing regression test (in which the constant cases have now been turned into _Static_asserts) already included that case.

2. Given that this has quite a few a few friends that need to be (partially, constant only, etc.) evaluated before / during type checking, is it time to start thinking about an abstraction / pass / organisation of these?

Fair point. One way of doing this is introducing exprts for each of those functions (like we already have for popcount) and have the simplifier do all this work.

[martin-cs]

I like the idea of the simplifier doing this because that way it can be used elsewhere, constant folded during symex, checked during trace construction, etc. Not entirely sure each one needs an ID, but, then again, what would be better?

[tautschnig]

I like the idea of the simplifier doing this because that way it can be used elsewhere, constant folded during symex, checked during trace construction, etc. Not entirely sure each one needs an ID, but, then again, what would be better?

This is now built on top of #5879, introducing a new find_first_set_exprt.