[ROCm][torch.compile] Adding ROCm-specific fusion pass for integrating aiter act/rms MXFP4 operators

[xytpai]

This PR adds few fusion passes for silu_mul_quant_mxfp4 and add_rmsnorm_quant_mxfp4
~ 2% Perf gain

[gemini-code-assist]

Code Review

This pull request introduces fusion passes for ROCm to optimize silu_mul operations with mxfp4 quantization. The changes include adding a new ROCmFusionPass, refactoring gemm_with_dynamic_quant to be compatible with torch.compile, and implementing new fused custom ops. The overall approach is sound and follows existing patterns for fusion passes in vLLM. I've found one issue related to incorrect type hints in a fake implementation function, which could cause problems with torch.compile.

[gemini-code-assist]

The type hints for gemm_with_dynamic_quant_fake are incorrect and do not match the function's implementation or its real counterpart gemm_with_dynamic_quant.

1. The x_scales parameter is type-hinted as torch.Tensor but has a default value of None. The type hint should be Optional[torch.Tensor] to reflect this.
2. The function is type-hinted to return torch.Tensor, but it implicitly returns None. The return type hint should be None.

These inconsistencies can cause issues with static type checkers and torch.compile's fake tensor propagation, which relies on correct function signatures for its analysis.

Suggested change

	def gemm_with_dynamic_quant_fake(
	result: torch.Tensor,
	x: torch.Tensor,
	weight: torch.Tensor,
	weight_scale: torch.Tensor,
	x_scales: torch.Tensor = None,
	rocm_use_aiter_fp4_asm_gemm: bool = False,
	out_dtype: Optional[torch.dtype] = torch.bfloat16,
	) -> torch.Tensor:
	return torch.empty((*x.shape[:-1], weight.shape[0]),
	dtype=out_dtype,
	device=x.device)
	return
	def gemm_with_dynamic_quant_fake(
	result: torch.Tensor,
	x: torch.Tensor,
	weight: torch.Tensor,
	weight_scale: torch.Tensor,
	x_scales: Optional[torch.Tensor] = None,
	rocm_use_aiter_fp4_asm_gemm: bool = False,
	out_dtype: Optional[torch.dtype] = torch.bfloat16,
	) -> None:
	return

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @xytpai.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[ProExpertProg]

Instead of creating a new pass, can we add these patterns to the existing passes? Also please wait for #24604 which will add better pattern matching utilities