Add extra llc step to produce assembly in the linker.

So, neither emit-llvm-bc or emit-llvm work well with save-temps. Therefore, I feel the current approach is still valid. This does not impact nvptx or any other target in any way. And I don't see how.

Here's a bit of background,
OffloadingPrefix was not getting properly set in the dependent actions of OffloadWrapperJobAction (which are backend [11] and assemble [12]). Since backend [11] and assemble [12] host-wrapper actions have same logic to the other host actions (3 & 4), those will overwrite the previous generated files from host-only actions.

Looks good to me. Thanks!

Fixed the assert.

It is because of how addClangTargetOptions is invoked. In case of save-temps, it is being invoked for all the actions resulting in target cc1 call. That's why all these invocations have -emit-llvm-bc. I guess we need Action as an argument to addClangTargetOptions.

emit-llvm-bc does not correctly solve the problem. It works because [input, compile, assemble, backend] actions collapse to a single action by driver. This single command handles emit-llvm-bc properly. But when save-temps is specified, this collapsing does not happen which messes up command line flags of the jobs and hence the output, for e.g., preprocessor command also has -emit-llvm-bc.

This does fixes the save-temps but only when -o is not specified. If -o is specified the name of host object file and host-wrapper object file (second last phase) is same, which fails the linker. This does not seem to be related to this patch.

Addressed review comments.

Can you use -check-prefixes=GCN,GFX8 and GCN,GFX9 so that update_mir_test_checks will common up the identical ones?

It does not work. Script warns as WARNING: Ignoring common prefixes: {'GCN'}: llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-umulo.mir

Addressed review comments.

I haave removed libomptarget-device-bc-path and have added amdgcn one. For diagnostic,
instead of having one per architecture, I have used the same and added second
parameter to specify arch.

LGTM. Thanks!

LGTM, thanks for fixing it.

• Added check for nogpulib
• Fixed diagnostic message

Addressed review comments.

Accidently missed some changes,

• Fix openmp-offload.c test failure
• Fix amdgpu-openmp-toolchain.c test failure

Ping!

• Use 0 for default -O option
• Rename addOptLevelArgs to addLLCOptArg

After addressing the review comments, I have internally verified changes on few simple test programs. They seem to be working fine.

Addressed review comments.

• Combined the toolchain creation logic for nvptx and amdgcn
• Replaced -Xopenmp-target with -emit-llvm-bc inside AMDGPUOpenMP.cpp
• Removed opt from pipeline

• Scalarize the vectors first
• Using widened operation for smaller types

Ping!

Hi, apologies for late reply as I got sidetracked to some other work.

• Moved common methods of HIP and OpenMP to base AMDGPUToolChain
• Removed unnecessary asserts

Fixed failing debian tests

Won't this just prevent us from building clang due to the missing cmake changes?

It compiles and builds fine, however, I wasn't actually aware such sanity checking being present. It turns out
the unknown files inside llvm/ will lead cmake to report error but such reporting will not happen inside clang. Maybe such checks
were not enabled inside clang. Anyways thanks for pointing out. I will keep that in mind in future.

Fix clang-tidy error

Moved ops close to ADDO

Removed global-isel-abort=0

Update AMDGPU barrier intrinsic

Ping!

Looks good, thanks.

Ping!

Ping!

Ping!

Removed redundant header

LGTM, thanks!

clang-format'ed the changes

Formatting and removed implicit uses

Removed unused code

Added lowerFor({V2S8})

Updated tests and clamping number of elements to 2

Updated data_sharing_stack_init_common

Only places where it was accessed are here and here. Jon's observation is correct. The maximum number of threads on both amdgcn and nvptx is 1024. However, on amdgcn, wave size is 64 and so maximum number of waves can be 16 and on nvptx, the warp size is 32 and maximum number of warps is 32.

@arsenm , let me know if it is good to land.

Updated review comments.

Added support for vector types.