Skip to content

Fix shared values in conditional code in the PostScript compilers - #22418

Open
zerotohero3 wants to merge 2 commits into
mozilla:masterfrom
zerotohero3:ps-type4-shared-values
Open

zerotohero3 wants to merge 2 commits into
mozilla:masterfrom
zerotohero3:ps-type4-shared-values

Conversation

@zerotohero3

Copy link
Copy Markdown

Fixes #22416

  • Compute the shared values used in the branches of a ternary node before its condition. When the first use of such a value was in a branch, it was never stored if the other branch was taken, so it was read as 0 with Wasm, or as whatever a previous call left in the tmp slot with JS.
  • In the Wasm compiler, compile a condition shared by several ternary nodes only once. The fast paths in _compileNodeAsBoolI32 compiled its operands for each use, which decremented their use count too many times, so their local could be reused for another value while still needed.

Besides the new tests, I checked the Wasm/JS compilers against the interpreter on randomly generated functions and on all the Type 4 functions in test/pdfs: with this patch and #22417, the only remaining differences are for 0 0 atan with negative zeros, which is an error in PostScript anyway.

A value used more than once is stored, in a Wasm local or in a JS tmp
slot, where it's compiled for the first time. When that happens in a
branch of a ternary node, the value is never stored if the other branch
is taken, so it's read as 0 (or as the value of another node reusing the
local) with Wasm, and as whatever a previous call left in the slot with
JS. For example `{ dup sin exch 0 gt { 1 add } if }` returns 0 instead of
`in0 sin` for any non-positive input.

Compute the shared values used in the branches before the condition,
which is fine since the operators have no side effects.
The fast paths in `_compileNodeAsBoolI32` compile the operands of a
comparison, or of a boolean operator, directly, so a condition shared by
several ternary nodes was compiled for each of them. The remaining use
count of its operands was then decremented too many times, hence their
local could be released, and reused for another value, while still
needed.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Wrong colors with a Type 4 function using a value in a conditional branch

2 participants