[LLVMdev] [PATCH][RFC] HSAIL Target

[Reid Kleckner]

Can you provide some high-level statistics on the amount of code involved
in the various pieces? It's a crude approximation of how complex the pieces
(backend, assembler, disassembler) are.

If HSAIL is similar to AMDIL and NVPTX, how does it compare to SPIR-V? Is
it more of a backend, with lots of lowering, or more of a portable program
representation?

On Wed, May 13, 2015 at 8:23 AM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

>  Hi,
>
> AMD would like to propose including an LLVM backend for the HSAIL target.
> Patches for review are attached and can also be found at
> https://github.com/HSAFoundation/HLC-HSAIL-Development-LLVM/ on the
> hsail-review branch. Most of the recent work is visible on the hsail-1.0f
> branch, which is based on an LLVM commit approximately 1 month before 3.6
> branched. The hsail-review branch is the content of hsail-1.0f with the
> minimal changes required to port it to trunk in the approximate squashed
> form I plan on eventually committing to the LLVM repository.
>
> First, background and a description of the backend:
>
> HSAIL is a virtual target machine similar in spirit to AMDIL and NVPTX. A
> language compiler produces HSAIL text (or the binary format, called BRIG)
> and an HSA implementation provides an HSAIL finalizer which produces a
> binary for execution on a physical device. This backend implements the HSA
> 1.0 standard published at http://www.hsafoundation.com/standards/. The
> AMD OpenCL 2.0 implementation uses HSAIL via LLVM when targeting any GPU
> device, supporting Sea Islands GPUs and later. This backend is unrelated to
> the R600 / AMDGPU target which is already in tree. This HSAIL backend is
> multivendor, and capable of supporting multiple generations of ISA from any
> one vendor. About 8 months ago, the HSAIL target was forked off of the
> internal version and I've been working since then to catch it up to LLVM
> trunk and into a state acceptable for upstreaming. To expedite this
> process, various features (such as image support, debug info, and a few
> optimizations) were dropped, so this version is currently not as full
> featured as the internal version. The intention is to gradually merge that
> functionality back into this version once upstream, and eventually base
> AMD’s internal version on the upstream target and be minimally divergent.
> There is still some work I believe needs to be done before it is ready to
> be committed, but at this point I think it is ready for others to start
> providing feedback on areas where I should be focusing to get there.
>
> With the current set of features this HSAIL backend is able to execute
> C++AMP programs by following the directions here:
> https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/HSA%20Support%20Status.
> Over time, we intend to evolve to a full C++17 compiler on the LLVM HSAIL
> back end with the ability to target the GPU for parallel regions. Other
> languages will also use this path over time.
>
> One noteworthy difference from how other targets are structured is there
> are two code emission paths in the backend. The first path, which is the
> original used by the internal OpenCL compiler, uses a third party library
> (libHSAIL) for code emission plugged into the AsmPrinter. The reason for
> this is partially legacy, and partially because the HSA specification
> defines its own object format, BRIG, which is unlike any of the supported
> object formats such as ELF. Supporting BRIG in MC would be a challenge
> (largely because it is not really streamable), but attempting to emit it
> using the standard infrastructure may be a consideration in the future.
> This path supports emitting object files and text output via libHSAIL's
> disassembler. The second path which I've implemented over the past few
> months uses a normal AsmPrinter emitting HSAIL text using the standard MC
> infrastructure, and does not support object output. The two paths have
> similar pass rates on the C++ AMP conformance test suite, and should
> produce the same output except for some whitespace and comment differences.
>
> The backend currently has a cmake option to control whether libHSAIL will
> be used or not, defaulting to using it if libHSAIL is found. Developers
> building LLVM with or without HSAIL support will not need libHSAIL to build
> the backend or run tests, all of which pass using either AsmPrinter.
> libHSAIL and associated assembler / disassembler can be found at
> https://github.com/HSAFoundation/HSAIL-Tools.
>
> Currently I have left it as an experimental target, not built by default.
> I have only implemented the build support necessary for cmake. I'm not
> planning on adding the autotools support, since hopefully that will be gone
> soon enough.
>
> My highest priority is to get the backend upstreamed as soon as possible,
> so I would appreciate feedback about any kinds of blocking issues on that.
>
> Thanks
>
> Matt Arsenault
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/2a6cb312/attachment.html>