Conv2d/Conv3d output-size constructors use R*dilation instead of the effective filter size ((R-1)*dilation+1)

Description

The output-size computing constructors in include/cutlass/conv/conv2d_problem_size.h (lines ~175-176) and include/cutlass/conv/conv3d_problem_size.h (~196 and ~224) subtract R * dilation instead of the effective filter extent ((R - 1) * dilation + 1):

P = ((H + pad_h + padding[1] - R * dilation_h) / stride_h) + 1;
Q = ((W + pad_w + padding[3] - S * dilation_w) / stride_w) + 1;
Z = ((D + pad_d + ... - T * dilation_d) / stride_d) + 1;

The library's own profiler computes cuDNN-compliant sizes with the standard formula (tools/profiler/src/conv2d_operation_profiler.cu lines ~275-303):

output = div_up(input + 2*pad - ((filter - 1) * dilation + 1) + 1, stride)

For dilation == 1 the two agree (R*1 == (R-1)*1+1), which is why existing tests pass. For dilation > 1 the constructors undersize P/Q/Z: e.g. H=8, R=3, dilation_h=2, pad=0, stride=1 gives P = 8-6+1 = 3 instead of the correct 8-5+1 = 4. Degenerate combinations can even produce non-positive extents (H=1, R=1, dil=3, pad=0 gives P=-1).

Any caller constructing a problem via these Tensor4DCoord/Tensor5DCoord constructors with dilation > 1 gets wrong output extents; downstream kernels then truncate or mis-map the output.

Suggested fix

Use (R - 1) * dilation_h + 1 (and the S/T analogues) in all three places.

Start with the output-size constructors in include/cutlass/conv/conv2d_problem_size.h around lines 175-176 and include/cutlass/conv/conv3d_problem_size.h around lines 196 and 224. Compare their extent calculations with the formula in tools/profiler/src/conv2d_operation_profiler.cu around lines 275-303, then verify dilation greater than one produces the expected P, Q, and Z values; done means all three constructors use the effective filter extent.