Skip to content

Fix LUT fusion treating an already-fused LUT node as a plain unary op#10756

Open
sachinhambar wants to merge 1 commit into
google:masterfrom
sachinhambar:fix/lut-fusion-invalid-unary-node
Open

Fix LUT fusion treating an already-fused LUT node as a plain unary op#10756
sachinhambar wants to merge 1 commit into
google:masterfrom
sachinhambar:fix/lut-fusion-invalid-unary-node

Conversation

@sachinhambar

Copy link
Copy Markdown

is_pure_unary_elementwise treated any xnn_node_type_unary_elementwise
node as a plain single-input op, reading inputs[0] unconditionally.
But a node already fused into a LUT (via
xnn_define_unary_elementwise_lut_in_place) has num_inputs == 2
(tensor + LUT table) and unary_operator == xnn_unary_invalid. If the
fusion pass reaches that node again — the outer loop in
xnn_subgraph_fuse_unary_quantized_into_lut can revisit the same slot
within a single pass, and xnn_subgraph_optimize can also be called
more than once on the same subgraph — it would misinterpret the LUT
node as an ordinary unary op and try to fuse it again.

`xnn_define_unary_elementwise_lut_in_place` converts a chain of unary
ops in place into a node with 2 inputs (tensor + LUT table) and
`unary_operator == xnn_unary_invalid`. `is_pure_unary_elementwise` did
not check for this, so if the fusion pass encounters that node again
it misreads `inputs[0]` as an ordinary single-input operand and tries
to fuse the LUT node into a further LUT.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant