[HIP] Add input type for HIP

[yaxunl]

Summary

This patch is split from https://reviews.llvm.org/D45212

Patch by Greg Rodgers.
Revised by Yaxun Liu.

[rjmccall]

LGTM.

[tra]

I'm getting confused about the order of the patches.
The patch stack phabricator displays in this patch is different compared to the stack in D44984. Which one should I trust?

[yaxunl]

In D45489#1070470, @tra wrote:

I'm getting confused about the order of the patches.
The patch stack phabricator displays in this patch is different compared to the stack in D44984. Which one should I trust?

Sorry I think I may misunderstand the parent/child relation between reviews. I thought a review depends on its parent reviews, i.e., parent reviews should be committed first. Is that correct? Thanks.

[yaxunl]

In D45489#1070929, @yaxunl wrote:

In D45489#1070470, @tra wrote:

I'm getting confused about the order of the patches.
The patch stack phabricator displays in this patch is different compared to the stack in D44984. Which one should I trust?

Sorry I think I may misunderstand the parent/child relation between reviews. I thought a review depends on its parent reviews, i.e., parent reviews should be committed first. Is that correct? Thanks.

I think it is just visual difference. The relations are the same.

[tra]

In D45489#1071044, @yaxunl wrote:

In D45489#1070929, @yaxunl wrote:

In D45489#1070470, @tra wrote:

I'm getting confused about the order of the patches.
The patch stack phabricator displays in this patch is different compared to the stack in D44984. Which one should I trust?

Sorry I think I may misunderstand the parent/child relation between reviews. I thought a review depends on its parent reviews, i.e., parent reviews should be committed first. Is that correct? Thanks.

I think it is just visual difference. The relations are the same.

Would it be possible to arrange the changes in order in which you apply them in the tree you are working on? If I want to try (partially) apply your parches in my tree, it would help to know that what I get matches your setup. Patch relationships as they are right now make intended order ambiguous.

[yaxunl]

In D45489#1071177, @tra wrote:

In D45489#1071044, @yaxunl wrote:

In D45489#1070929, @yaxunl wrote:

In D45489#1070470, @tra wrote:

I'm getting confused about the order of the patches.
The patch stack phabricator displays in this patch is different compared to the stack in D44984. Which one should I trust?

Sorry I think I may misunderstand the parent/child relation between reviews. I thought a review depends on its parent reviews, i.e., parent reviews should be committed first. Is that correct? Thanks.

I think it is just visual difference. The relations are the same.

Would it be possible to arrange the changes in order in which you apply them in the tree you are working on? If I want to try (partially) apply your parches in my tree, it would help to know that what I get matches your setup. Patch relationships as they are right now make intended order ambiguous.

I reordered them as a simple linear relation. In the stack display, the patches should be applied from bottom to top.

cfe/trunk/include/clang/Driver/Types.def

 
 // C family source language (with and without preprocessing).
 TYPE("cpp-output",               PP_C,         INVALID,         "i",     "u")
 TYPE("c",                        C,            PP_C,            "c",     "u")
 TYPE("cl",                       CL,           PP_C,            "cl",    "u")
 TYPE("cuda-cpp-output",          PP_CUDA,      INVALID,         "cui",   "u")
 TYPE("cuda",                     CUDA,         PP_CUDA,         "cu",    "u")
 TYPE("cuda",                     CUDA_DEVICE,  PP_CUDA,         "cu",    "")
+TYPE("hip-cpp-output",           PP_HIP,       INVALID,         "cui",   "u")
+TYPE("hip",                      HIP,          PP_HIP,          "cu",    "u")
+TYPE("hip",                      HIP_DEVICE,   PP_HIP,          "cu",    "")
 TYPE("objective-c-cpp-output",   PP_ObjC,      INVALID,         "mi",    "u")
 TYPE("objc-cpp-output",          PP_ObjC_Alias, INVALID,        "mi",    "u")
 TYPE("objective-c",              ObjC,         PP_ObjC,         "m",     "u")
 TYPE("c++-cpp-output",           PP_CXX,       INVALID,         "ii",    "u")
 TYPE("c++",                      CXX,          PP_CXX,          "cpp",   "u")
 TYPE("objective-c++-cpp-output", PP_ObjCXX,    INVALID,         "mii",   "u")
 TYPE("objc++-cpp-output",        PP_ObjCXX_Alias, INVALID,      "mii",   "u")
 TYPE("objective-c++",            ObjCXX,       PP_ObjCXX,       "mm",    "u")

cfe/trunk/lib/Driver/Driver.cpp

ActionBuilderReturnCode addDeviceDepences(Action *HostAction) override {
 
       // If we are dealing with an input action, replicate it for each GPU
       // architecture. If we are in host-only mode we return 'success' so that
       // the host uses the CUDA offload kind.
       if (auto *IA = dyn_cast<InputAction>(HostAction)) {
         assert(!GpuArchList.empty() &&
                "We should have at least one GPU architecture.");
 
-        // If the host input is not CUDA, we don't need to bother about this
-        // input.
-        if (IA->getType() != types::TY_CUDA) {
+        // If the host input is not CUDA or HIP, we don't need to bother about
+        // this input.
+        if (IA->getType() != types::TY_CUDA &&
+            IA->getType() != types::TY_HIP) {
           // The builder will ignore this input.
           IsActive = false;
           return ABRT_Inactive;
         }
 
         // Set the flag to true, so that the builder acts on the current input.
         IsActive = true;
 
         if (CompileHostOnly)
           return ABRT_Success;
 
         // Replicate inputs for each GPU architecture.
-        for (unsigned I = 0, E = GpuArchList.size(); I != E; ++I)
-          CudaDeviceActions.push_back(C.MakeAction<InputAction>(
-              IA->getInputArg(), types::TY_CUDA_DEVICE));
+        auto Ty = IA->getType() == types::TY_HIP ? types::TY_HIP_DEVICE
+                                                 : types::TY_CUDA_DEVICE;
+        for (unsigned I = 0, E = GpuArchList.size(); I != E; ++I) {
+          CudaDeviceActions.push_back(
+              C.MakeAction<InputAction>(IA->getInputArg(), Ty));
+        }
 
         return ABRT_Success;
       }
 
       return IsActive ? ABRT_Success : ABRT_Inactive;
     }
 
     void appendTopLevelActions(ActionList &AL) override {

cfe/trunk/lib/Driver/Types.cpp

bool types::isAcceptedByClang(ID Id) {
   default:
     return false;
 
   case TY_Asm:
   case TY_C: case TY_PP_C:
   case TY_CL:
   case TY_CUDA: case TY_PP_CUDA:
   case TY_CUDA_DEVICE:
+  case TY_HIP:
+  case TY_PP_HIP:
+  case TY_HIP_DEVICE:
   case TY_ObjC: case TY_PP_ObjC: case TY_PP_ObjC_Alias:
   case TY_CXX: case TY_PP_CXX:
   case TY_ObjCXX: case TY_PP_ObjCXX: case TY_PP_ObjCXX_Alias:
   case TY_CHeader: case TY_PP_CHeader:
   case TY_CLHeader:
   case TY_ObjCHeader: case TY_PP_ObjCHeader:
   case TY_CXXHeader: case TY_PP_CXXHeader:
   case TY_ObjCXXHeader: case TY_PP_ObjCXXHeader:
default:
     return false;
 
   case TY_CXX: case TY_PP_CXX:
   case TY_ObjCXX: case TY_PP_ObjCXX: case TY_PP_ObjCXX_Alias:
   case TY_CXXHeader: case TY_PP_CXXHeader:
   case TY_ObjCXXHeader: case TY_PP_ObjCXXHeader:
   case TY_CXXModule: case TY_PP_CXXModule:
   case TY_CUDA: case TY_PP_CUDA: case TY_CUDA_DEVICE:
+  case TY_HIP:
+  case TY_PP_HIP:
+  case TY_HIP_DEVICE:
     return true;
   }
 }
 
 bool types::isLLVMIR(ID Id) {
   switch (Id) {
   default:
     return false;

 bool types::isCuda(ID Id) {
   switch (Id) {
   default:
     return false;
 
   case TY_CUDA:
   case TY_PP_CUDA:
   case TY_CUDA_DEVICE:
+  case TY_HIP:
+  case TY_PP_HIP:
+  case TY_HIP_DEVICE:
     return true;
   }
 }
 
 bool types::isSrcFile(ID Id) {
   return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
 }