[LLVMdev] [PATCH][RFC] HSAIL Target

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Jun 22 09:31:30 PDT 2015


> 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.

This part is scary.

Having a third party library dependency is very undesirable from a testing
perspective.

One of the important property of MC is avoiding the need for two code paths
in the code generator.

If MC cannot support the format you need, we should work on fixing that in
a way that maintains the property that most code is shared when writing
objects or assembly. This is a need that is shared by Webassembly I think.

My suggestion would be to start with just the assembly printing path and
work to figure out what needs to happen in MC.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150622/ebcd8fc6/attachment.html>


More information about the llvm-dev mailing list