Add HIP backend

[amd-asalykov]

Updated version of #96

How to install:

uv add torch --index pytorch=https://download.pytorch.org/whl/rocm7.1

Run on MI350X/MI355X:

uv run python scripts/generate_and_eval_single_sample.py gpu_arch=gfx950 backend=hip dataset_src=huggingface level=1 problem_id=22 server_type=google model_name=gemini/gemini-2.5-flash

Run on MI300X/MI325X:

uv run python scripts/generate_and_eval_single_sample.py gpu_arch=gfx942 backend=hip dataset_src=huggingface level=1 problem_id=22 server_type=google model_name=gemini/gemini-2.5-flash

[simonguozirui]

thanks so much @amd-asalykov, validating on a bare metal MI350X right now. Also thanks @laasya-konidala for setting things up and checking the codebase + verifying!

[salykova]

@simonguozirui you might have noticed that in the current implementation we rely on os.environ["CXX"] = "hipcc" in src/kernelbench/prompts/model_new_ex_add_hip.py to make pytorch's load_inline work with hip kernels. We didn't explicitly tell LLMs to include this LOC in the generated kernels. Instead we expect that LLMs will include it automatically based on the model_new_ex_add_hip.py example. As an alternative, we could introduce a backend-specific prompt and explicitly ask LLMs to include os.environ["CXX"] = "hipcc"

[simonguozirui]

Gotcha os.environ["CXX"] = "hipcc" triggers the HIP compiler and prevents it from running hipify (we had this issue last year when @willhu-jpg and I tried to implement AMD support; it would just hipify CUDA code #37). We can keep that as part of the in-context example which becomes a part of the prompt automatically, the same way we treat other backends like TK that need special include library (no need for backend specific warnings and instructions)

Added a few guardrails to ensure a separate AMD and NVIDIA code path

Two more small things to close things off

• reward hack checking -> hip kernel must use hip-related keywords (regex-based matching)
• L2 cache thrashing, for clearing cache rn we allocate a big tensor to thrash it, so for AMD need to see if the tensor size still works well there

[amd-asalykov]

Hi @simonguozirui, I updated the PR and included hip keywords checks fd4589f Could you please review the changes? CUDA/HIP kernels are very similar in terms of keywords, so additionally to the standard CUDA checks I only added a check for the hipcc compiler

Regarding L2 cache clearing: I see KernelBench uses 268MB buffer tensor

KernelBench/src/kernelbench/timing.py

Line 139 in b6c5259

dummy=torch.empty((32, 1024, 1024), dtype=torch.int64, device=device)

it's sufficient for AMD GPUs and no changes are needed here

[salykova]

@simonguozirui bumping up

[simonguozirui]

awesome yes we will need to trigger the hipcc compiler

[simonguozirui]

as we require os.environ["CXX"] = "hipcc" in the LM generated code to trigger hipcc rather than hipify

[simonguozirui]

Looks great, thanks so much for investigating the cache size for cache flushing for AMD.
Re: reward hack checker, I think these should suffice as the minimum ones, but let's definitely keep an eye out as there might be new behavior for HIP kernels (I haven't spent as much time programming AMD). We can make updates to it in future PR and ultimately end user should check for hacks and be careful (as specified in EVAL.md).

Thank you @laasya-konidala for running and verifying!