Page MenuHomePhabricator

[GPGPU][PPCGCodeGen][GPUJIT] Added AMD support to GPGPU code generation
Needs ReviewPublic

Authored by PhilippSchaad on Sep 3 2017, 12:13 PM.

Details

Summary

We can now use the AMDGPU back-end to generate valid AMD kernel code, which
gets linked by LLD to valid AMD executables. The OpenCL runtime can execute
said kernels. This requires the ROCm driver stack to be installed, supported
are any AMD GPUs from the Fiji family and up. The specific GPU family can be
chosen when compiling, default is Fiji.

The LLD pass is currently a bit of a hack with a temporary file, but sadly this
is the only way this is possible at the moment, since LLD is not available as a
from-code pass. The way the temp file is being handled will change, such that
the name is random/different between compilations.

Event Timeline

PhilippSchaad created this revision.Sep 3 2017, 12:13 PM
  • Updated test cases to reflect changes and fixed formatting
  • Improved temporary file handling.
  • Fixed error in test case
philip.pfaffe edited edge metadata.Sep 19 2017, 2:01 AM

I don't fully understand the reasoning behind this, and I dislike the LLD hack for a couple of reasons:

  • Why invoke a program instead of linking against lld?
  • What if lld is not installed? Why not default to ld?
  • Generally I feel like this is a huge violation of layering.

Can you elaborate on why this is necessary?

Further, LLVM offers OS-independent abstractions for interfacing with the system in the llvm::sys and llvm::sys::fs namespaces. Please use those instead of POSIX.

I agree, it is a really 'disgusting' hack at this point.

  • So the reason lld is used instead of ld is simply that I do not know and have not been able to test if ld works. The AMDGPU backend documentation here specifically mentions lld, so I felt like that was the safest bet. But you are absolutely right, if ld works, that is the better default.
  • As for the program call: I do not know of any other way of going about this currently. I've asked on the mailing list and was told that there is no way of reaching lld from code at this point in time.
  • I will look into the elimination of POSIX specific system interactions, and instead try to adapt this hack to use llvm's own abstractions. Thank you for pointing that out, I was unaware of that!