[HIPIFY][feature] Implicit hipification of local header files

[ranapratap55]

Problem Statement

hipify-clang currently only transforms the main source file passed as input. Local (quoted) headers included in the main file remain same as CUDA code. These headers often cannot be hipified individually because they are not self-contained headers which requires types, operators, and definitions from preceding includes in the parent source.

Example: dxtc.cu includes CudaMath.h, which uses float3 operators (+=, *, -) defined in helper_math.h. Hipifying CudaMath.h alone fails because these operators are unavailable. Similar cases:

• bodysystemcpu_impl.h
• MonteCarlo_reduction.cuh
• fastWalshTransform_kernel.cuh

Purpose

When hipify-clang sample.cu is run, the tool now implicitly detects and hipifies all local headers. No additional flags required.

#2402 (comment)

2. Implement the ability to implicitly hipify all header files that are included in the main file.

This redesign is based on feedback from #2275 and earlier iterations of this PR(#2402):

• Implicit by default: no --local-headers / --local-headers-recursive flags
• Single opt-out: --skip-local-headers when header processing is not desired

With #2349, we addressed nvcc's implicit cuda_runtime.h. Now, with this PR(#2402) we are implicitly transforming project-level header dependencies.

Solution

Local quoted headers hipified automatically, no flags needed.
hipify-clang sample.cu -I ../../../Common/

Skip header processing if not desired
hipify-clang --skip-local-headers sample.cu -I ../../../Common/

Supersedes #2275

[emankov]

Can we say that the main purpose of this PR is to allow hipifying header files individually as main translation units?

[ranapratap55]

Can we say that the main purpose of this PR is to allow hipifying header files individually as main translation units?

Yes, correct. The main purpose is to allow hipifying local header files as main translation units. We are doing it by injecting their preceding includes from the parent source file using Clang's -include ArgumentsAdjusters which is to provide the necessary compilation context.

This feature is enabled via --local-headers / --local-headers-recursive and only applies to local (quoted) headers referenced in the main source file.

[emankov]

the parent source

How do we guarantee finding the parent source(s) for a particular header file so we can hipify it as the main translation unit?

[ranapratap55]

the parent source

How do we guarantee finding the parent source(s) for a particular header file so we can hipify it as the main translation unit?

We don't need to discover/guess the parent source file. The user provides it explicitly while hipifying. The main source file passed to hipify-clang is always the parent. --local-headers simply extends hipification to that source file's local headers, using the source file itself as the context for preceding includes.

For example: hipify-clang --local-headers sample.cu: here sample.cu is known parent for its local headers (header1.h, header2.h, etc.,).

[emankov]

hipify-clang --local-headers sample.cu

That is what worries me most.

1. The user should know or learn about the main source file, or, in general, the source files that include that particular header file.
2. sample.cu is not a header file. Here we have misleading information for the end users.
3. We need to explain somewhere, somehow, this tricky feature (actually a workaround).
4. Finally, it makes hipify-clang even more complicated in use, which we definitely do not want, as users already consider hipify-clang complicated enough to prefer hipify-perl usage instead. And we want the opposite. We want users to prefer hipify-clang. It means that we need to simplify it AMAP and do more work under the hood implicitly.

Technically, the main problem is that we are trying to treat a file, a header file, which is not self-contained, as a source file for hipification (actually, compilation).

I want us to think about other approaches here.
For instance:

1. Warn (besides compiler’s error messaging) the user about imposibility to hipify a header file, which is not self-contained.
2. Implement the ability to implicitly hipify all header files that are included in the main file.
3. Hipify everything in the provided folder.

[ranapratap55]

hipify-clang --local-headers sample.cu

That is what worries me most.

1. The user should know or learn about the main source file, or, in general, the source files that include that particular header file.
2. sample.cu is not a header file. Here we have misleading information for the end users.
3. We need to explain somewhere, somehow, this tricky feature (actually a workaround).
4. Finally, it makes hipify-clang even more complicated in use, which we definitely do not want, as users already consider hipify-clang complicated enough to prefer hipify-perl usage instead. And we want the opposite. We want users to prefer hipify-clang. It means that we need to simplify it AMAP and do more work under the hood implicitly.

Technically, the main problem is that we are trying to treat a file, a header file, which is not self-contained, as a source file for hipification (actually, compilation).

I want us to think about other approaches here. For instance:

1. Warn (besides compiler’s error messaging) the user about imposibility to hipify a header file, which is not self-contained.
2. Implement the ability to implicitly hipify all header files that are included in the main file.
3. Hipify everything in the provided folder.

As per our discussions/suggestions, I've reworked this PR to implement suggestion 2.
Local header hipification is now implicit by default. hipify-clang sample.cu automatically detects and hipifies all local headers recursively, no flags needed. Added --skip-local-headers as the single opt-out mechanism.

I will raise 2 separate PRs as a follow up for:

1. Warn the user for non-self-contained headers
2. Folder-level hipification

Updated PR title and description to reflect the changes.