馃悰 Describe the bug
aten._fft_r2c has no portable CPU kernel. When a partitioner leaves it on the CPU backend, to_executorch() succeeds and writes a .pte, but the program cannot be loaded: load_method("forward") fails with 0x14 (Error::OperatorMissing).
The failure surfaces at load time rather than at partition time, so an export pipeline reports success and produces an artifact that is dead on arrival.
Repro (ExecuTorch 1.4.1, macOS arm64):
class Frontend(torch.nn.Module):
def forward(self, x): # x: [T, 512]
return torch.fft.rfft(x).abs().pow(2.0)
ep = torch.export.export(Frontend().eval(), (torch.randn(1000, 512),))
prog = to_edge_transform_and_lower(
{"forward": ep},
transform_passes=get_default_passes(),
partitioner=[MLXPartitioner()], # any partitioner that declines the op
compile_config=EdgeCompileConfig(_check_ir_validity=False, _skip_dim_order=True),
).to_executorch()
Path("m.pte").write_bytes(prog.buffer)
Runtime.get().load_program("m.pte").load_method("forward")
# RuntimeError: Failed to load method forward, error: 0x:14
Partitioner log confirms the op is declined and left to CPU:
no handler for target=<EdgeOpOverload: aten._fft_r2c.default
Found while exporting an FSMN VAD model whose feature front-end uses torch.fft.rfft(...).abs().
Two separate asks
- Provide a portable CPU kernel for
aten._fft_r2c (real-to-complex FFT is common in audio front-ends).
- Independently of (1), fail at partition/lowering time when an op is left undelegated and no kernel exists for it, instead of emitting a
.pte that fails at load. A build-time error naming the op would have saved a lot of guessing here.
Workaround
For the |rfft(x)|**2 case the FFT can be replaced by a real DFT written as two matmuls, which every backend lowers:
Re = x @ cos_basis, Im = -(x @ sin_basis), |X|**2 = Re**2 + Im**2
Measured max abs error 2e-6 against the float reference on the model above.
Versions
ExecuTorch 1.4.1, torch 2.14.0.dev20260702, macOS arm64 (M4).
馃悰 Describe the bug
aten._fft_r2chas no portable CPU kernel. When a partitioner leaves it on the CPU backend,to_executorch()succeeds and writes a.pte, but the program cannot be loaded:load_method("forward")fails with0x14(Error::OperatorMissing).The failure surfaces at load time rather than at partition time, so an export pipeline reports success and produces an artifact that is dead on arrival.
Repro (ExecuTorch 1.4.1, macOS arm64):
Partitioner log confirms the op is declined and left to CPU:
Found while exporting an FSMN VAD model whose feature front-end uses
torch.fft.rfft(...).abs().Two separate asks
aten._fft_r2c(real-to-complex FFT is common in audio front-ends)..ptethat fails at load. A build-time error naming the op would have saved a lot of guessing here.Workaround
For the
|rfft(x)|**2case the FFT can be replaced by a real DFT written as two matmuls, which every backend lowers:Measured max abs error 2e-6 against the float reference on the model above.
Versions
ExecuTorch 1.4.1, torch 2.14.0.dev20260702, macOS arm64 (M4).