Measure the LRB backend's compiled kernel footprint with cuobjdump #12474

Area

CUB

Problem

Architecture-selected entry types can multiply compiled kernel specializations even when a sort performs the same number of runtime launches. The LRB backend needs a matched comparison of compiled kernel symbols, device-code size, and actual execution behavior.

Proposed work

• Build minimal representative callers for current CUB, internal LRB, and selective public dispatch with identical compiler versions, flags, RDC settings, and GPU targets.
• Use cuobjdump to enumerate device-code images and kernel symbols per target. Demangle and distinguish unique C++ specializations from architecture-specific versions of one specialization.
• Expand a controlled matrix of key/iterator types, sorting directions, and supported overloads; compare selector-based kernels with architecture-selected entry types where relevant.
• Record compile/link time and device-code size alongside kernel-symbol counts.
• Use a runtime trace to count launches separately: cuobjdump inspects compiled code and cannot by itself show how many kernels a call launches.

Validation / completion criteria

• Produce a reproducible report with exact revisions, build commands, per-target symbol counts, device-code size, and runtime launch sequences.
• Explain each additional specialization or launch and propose a focused change where it is unnecessary.
• Confirm that host setup can select matching tuning without encoding every host-selected policy in GPU kernel template arguments.

Context

Follow-up to the LRB segmented-sort backend in #12236.

Related follow-ups

• [FEA]: Enable selective LRB public dispatch without additional runtime launches #12473
• Compare occupancy-based LRB grids with the fixed SM multiplier #12472