Repository navigation
Conversation
The new option controls what happens when DynComp reaches the default case for a binary, ternary, or quaternary VEX operation that it does not handle. "panic" (the default) stops, as before. "warn" prints a warning once per operation and approximates the operation by merging its operands' tags.
In warn mode, do not merge operands that appear to be rounding modes, shift amounts, or lane indices; treat boolean-valued ops as comparisons; and treat other ops as non-interactions in units and comparisons modes. Also realign and clarify the --help text.
|
@coderabbitai review |
|
|
@coderabbitai review |
|
|
@coderabbitai review |
|
|
@coderabbitai review |
|
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
…unary operation codespecs#85 replaced report_unhandled_op_DC by approximate_unhandled_op_DC, which handled only binary, ternary, and quaternary operations. An unhandled unary operation still returns the tag of its operand.
…RF PRs codespecs#89-codespecs#95 Both upgrades should wait for them: codespecs#89, codespecs#90, codespecs#91, and codespecs#95 change dwarf.c (and codespecs#90/codespecs#95 change mc_main.c and mc_include.h), and codespecs#85-codespecs#88 change dyncomp_translate.c. codespecs#85's --dyncomp-unhandled-ops=warn and codespecs#87's explicit unary handling also change how to find unhandled IROps.
markro49
left a comment
There was a problem hiding this comment.
again no comments on dyncomp_translate.c
the kvasir changes for the option look ok
This pull request adds the option
--dyncomp-unhandled-ops=panic|warn. When DynComp reaches thedefaultcase for a binary, ternary, or quaternary operation that it does not handle, thedefaultcase calls the new functionapproximate_unhandled_op_DC:panic(the default) prints the operation and stops, as before.warnprints a warning once per operation and approximates the operation.The approximation guesses each operand's role from its type, as given by
typeOfPrimop. It ignores operands that it guesses are rounding modes (a first operand of typeI32when the result or another operand is a floating-point or vector value), shift amounts, or lane indices (a later operand of typeI8when the first operand is not of typeI8). The remaining operands are the "data operands". Then:I1and that has 2 data operands is treated as a comparison: the data operands' tags are merged, and the result gets tag 0.--dyncomp-interactions=all: the data operands' tags are merged, and the result gets the merged tag. Under--dyncomp-interactions=unitsand--dyncomp-interactions=comparisons, it is treated as a non-interaction (the result gets tag 0), because it might be, for example, a multiplication.--dyncomp-interactions=none, every operation is treated as a non-interaction.Merging can over-approximate comparability (Daikon then checks more candidate invariants, so it may report extra, irrelevant invariants), and treating an operation as a non-interaction can under-approximate it (Daikon may then miss invariants). The warning says which approximation was used.
The option is listed in
--help. codespecs/daikon#894 documents it in the Daikon manual.This is one of three pull requests split from #83. It is independent of #86. #87 builds on both, also uses
approximate_unhandled_op_DCfor unary operations, and makes the approximation of a comparison merge with #104's dirty call.#123 makes every merge of tags go through
mkMergeTags_DCorstmtMergeTagsReturn0_DC, but no branch contains both #123 and this pull request, whoseapproximate_unhandled_op_DCcreates the clean calls ofMC_(helperc_MERGE_TAGS),MC_(helperc_MERGE_3_TAGS), andMC_(helperc_MERGE_4_TAGS)withmkIRExprCCall. Whichever of this pull request and #123 lands second should route those merges throughmkMergeTags_DC.