A layer's `add_weight`-created weight has an empty points-to set where `call` reads it, in every context of the vendored `Conv1d`, so neither the matmul's dtype rule nor its feed can use it

[khatchad]

In the vendored gpt-2 fixture, the weight a Conv1d layer creates in build with self.add_weight("cov1d_weights", shape=[...], dtype=tf.float32, initializer=...) has an empty points-to set where call reads it as the second operand of tf.matmul, in every one of the layer's 48 calling contexts. An add_weight call with an explicit dtype whose result never reaches the field read is a modeling gap by this repository's own rule (an empty points-to set is a bug to find, not a behaviour to work around), and it is on the critical path of #937: it blocks both routes by which the matmul could learn its dtype.

Demonstrated

The matmul generator's caller walk for the b operand logs, for every Conv1d context:

getArgumentPointsToSet: caller script layers.feed_forward.py.Conv1d.call.do()LRoot; [ctx#...] instr 42 = invokeFunction < PythonLoader, LCodeBody, do()LRoot; > 43,31,46 @31 ... argValNum=46
getArgumentPointsToSet: caller analysis of tensorflow.functions.matmul.do()LRoot; [ctx#...] found no argument at pos=1 name=b; returning empty.

The argument is located (value 46, the self.weight field read), and its points-to set is empty, so the walk reports no argument. The field read carries no dataflow state either (no tensor variable for value 46 in Conv1d.call's dump). By contrast, the same fixture seeds add_weight results in LayerNormalization.build (gamma, beta) and EmbeddingLayer.build, and a minimal fixture with the same build and call in a layer constructed directly by a model resolves its weight to (4, 4) float32 at the matmul. Nothing is seeded from Conv1d.build at all: no add_weight generator is found for any value in that node, although the node exists in the call graph and its two add_weight invokes dispatch to the keyword trampolines.

What Differs, Inferred

Two things distinguish Conv1d from the layers whose weights resolve, and either could be the cause: it is constructed inside another layer's __init__ (MultiHeadAttention and FeedForward each build two), so its build runs under a doubly nested trampoline context. And its first add_weight passes initializer=tf.random_normal_initializer(stddev=..., mean=...), a call result, where the resolving layers pass an initializer object without keyword arguments. Which one it is would be settled by a fixture that varies them one at a time.

Consequences

The matmul's dtype rule takes a's dtype when resolved and b's otherwise, so with b empty b never decides, and where a's generator-time read is unknown (the second instance of each Conv1d pair, #937) the seed is unknown. The dataflow repair is blocked by the same absence, and this is measured rather than inferred: the matmul's feed composes pairs of both operands' members and b carries none, so the feed composes nothing, and a temporary line in the engine's unfed-seed restore shows the matmul's and the add's suppressed seeds being put back unchanged in every Conv1d context (? of unknown in the second instance's contexts, ? of float32 in the first's). The probe's certificate, so the count reads as measured: its unconditional entry line printed once, entered with 294 suppressed seeds, and 112 restores followed in the same run; two earlier runs of the same probe printed no entry line (one had not compiled, one selected a test method that no longer existed) and their zeros were discarded. A resolved b would give the matmul its dtype at seed time or through the feed, either of which removes the unknown that the residual add's fill later composes into the loop-carried arm (#936). That makes this the second repair path for the same value that is also absent, which is why it is filed on its own rather than folded into either issue.

[khatchad]

Cause pinned by a five-cell fixture differential, with the two candidates the body named both refuted: the weight is empty because the layer's base class, tf.keras.layers.Layer, is reached through a wildcard import of a module that imports tensorflow, and a class whose base arrives that way does not inherit the shell's add_weight. The self.add_weight(...) call in its build has no call-graph target, so the weight is never allocated, and every read of it is empty.

The Cells

Each cell is a layer whose build creates one weight with add_weight and whose call passes that weight to a sink, so the sink's parameter reads the weight's resolution directly. The direct cell is the positive control.

Cell	Construction	Weight at the sink
direct	import tensorflow as tf, constructed by the model	(4, 4) float32
initializer	the call-valued initializer=tf.random_normal_initializer(stddev=..., mean=...)	(4, 4) float32
nested	constructed inside another layer's __init__	(4, 4) float32
both	the two above together	(4, 4) float32
wildcard	the module does from tf_utils import *, where tf_utils.py is import tensorflow as tf	no tensor parameter

The fourth cell is there because one-factor-at-a-time cannot see an interaction. It resolves, so neither candidate nor their combination is the cause. The fifth cell is the vendored construction: feed_forward.py is the only one of the four vendored layer modules that reaches tensorflow through from utils.tf_utils import *, and it is the module that defines Conv1d. A plain sibling in the same multi-file fixture (import tensorflow as tf, otherwise identical) resolves (4, 4) float32.

What Resolves And What Does Not, In The Wildcard Layer

Its call's parameter reads (2, 4) float32, and its tf.matmul(x, self.w) dispatches to the matmul summary (the callee appears with that call as caller) and reads ? of float32, the dtype from a and the shape lost to the empty b. So a call through the wildcard-bound tf resolves, which is what #665 fixed (its pull request forwards the source module's named bindings to global reads, including reads inside class methods). What does not resolve is the base class: the add_weight summary appears with the plain sibling's build as caller 46 times in the log and with the wildcard layer's build as caller 0 times. The class-definition-time lookup of tf.keras.layers.Layer through the wildcard binding is a different path from a global read in a method body, and it is the path this issue's fix has to reach. The closed issue's stated condition (the model's prediction parameter typing in the three gpt-2 fixtures, and its probes flipping positive) still holds, so this is new with that issue as the nearest prior, not a reopening.

Consequence For The Rows

With the base class resolved, Conv1d's weight allocates, the matmul's b carries a dtype and a shape, the matmul's seed and feed both have what they need, the restored-seed ⊤ on the layer's output goes away, and the chain in #936 loses its ⊤ operand. The eight parameters attributed here are predicted to emit signatures at that point. The witness in #939 is predicted to vanish at the same time without that issue being fixed, as recorded there.

[khatchad]

On the relation to #665, so it is not re-litigated from that issue's title: that issue closed with no comment, so it has no stated closing condition, and its pull request's stated payoff still holds, so nothing there has failed and nothing reopens. Its stated problem, wildcard imports not forwarding the source module's own import bindings, does have a surviving instance, which is this issue: the fix taught global reads to follow the binding (inside class methods included), and the class-definition-time base lookup is a different path that never adopted it. So tf.matmul resolves in the very class whose base does not, and the defect sits at the site the mechanism was not adopted at. The closed issue carries a comment pointing here. A one-line closing comment there would have made this a free question.

[khatchad]

The fix is ponder-lab#866. Partition of the eight parameters, traced on the vendored fixture after it: four to this root (the decoder block's input, the layer norm's, the head split's, and the convolution layer's own weight: the weight allocates, the matmul's and the add's seeds are no longer restored, the loop-carried pair's unknown member becomes float32, and the head split's phantom is gone), and four to #940 (the head merge's input and the three attention operands: those were predicted by class here and the prediction failed on measurement, and the head split's reshape keeps an unknown-dtype seed member beside the delivered float32, which the transpose carries). The same partition is recorded on #937 and in the pull request body.