Statically-known existence conditions: drop or simplify the check#259
Open
AaronWebster wants to merge 1 commit into
Open
Statically-known existence conditions: drop or simplify the check#259AaronWebster wants to merge 1 commit into
AaronWebster wants to merge 1 commit into
Conversation
Many Emboss schemas have fields whose existence_condition the front
end has already constant-folded to a boolean literal:
* \`if false:\` fields are never present, so Ok() needs no check
for them at all. PR 241 still emitted the full has_X() guard +
Ok() check; both branches are dead.
* Unconditional fields (and \`if true:\` fields) carry a literal
\`true\` existence. has_X() is always Known and always true, so
the standard ok_method_test pattern
if (!has_x().Known()) return false;
if (has_x().ValueOrDefault() && !x().Ok()) return false;
collapses to a bare
if (!x().Ok()) return false;
A fast pre-pass in _generate_optimized_ok_method_body recognizes
both shapes (existence_condition.type.boolean has a literal value)
and routes them to the short emit paths. \`if false:\` fields are
skipped; the always-true case emits the bare Ok() check.
Wide golden churn: most structs have several unconditional fields
(virtual size fields like IntrinsicSizeInBytes/Max/Min plus any
non-conditional payload), so most Ok() methods shrink by several
lines apiece.
The docstring on _generate_optimized_ok_method_body is rewritten to
describe the four emit paths the function now routes fields through
(skipped / unconditional / switch arm / ok_method_test) — the
original PR 241 docstring referenced only two paths and a duplicate-
case fallthrough that no longer exists.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Many Emboss schemas have fields whose
existence_conditionthe front end has already constant-folded to a boolean literal:if false:fields are never present, soOk()needs no check for them at all. PR Optimize C++ generated code for structures with many conditional fields #241 still emitted the fullhas_X()guard +Ok()check; both branches are dead.if true:fields) carry a literaltrueexistence.has_X()is alwaysKnownand always true, so the standardok_method_testpattern collapses from two lines to one bareif (!x().Ok()) return false;check.A fast pre-pass in
_generate_optimized_ok_method_bodyrecognizes both shapes and routes them to the short emit paths.if false:fields are skipped; the always-true case emits the bareOk()check. All unconditional fields share one group so they emit contiguously at the position of the first such field — preserves PR #241's field-batching shape so the compiler's view of the function body stays tight.The docstring on
_generate_optimized_ok_method_bodyis rewritten to describe the four emit paths the function now routes fields through (skipped / unconditional / switch arm /ok_method_test).Size impact (cumulative vs. master)
Incremental delta vs. #258: 0 across the board. The C++ compiler optimizes both source patterns identically at
-Os, so this PR is a source-quality improvement (32 golden headers shrink by hundreds of lines apiece, generated code is easier to read) with no runtime machine-code cost.Stacked on #258.