<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2015, at 9:31 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" class="">rafael.espindola@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""> <br class="">
> 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.</p><p dir="ltr" class="">This part is scary.</p><p dir="ltr" class="">Having a third party library dependency is very undesirable from a testing perspective. </p><p dir="ltr" class="">One of the important property of MC is avoiding the need for two code paths in the code generator. </p><p dir="ltr" class="">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. </p><p dir="ltr" class="">My suggestion would be to start with just the assembly printing path and work to figure out what needs to happen in MC. </p></div></blockquote>I wonder if we need a ‘raw’ version of MC which literally only emits bytes to the stream and doesn’t nothing else. Of course there would be a ton of details to work out, like whether the raw MC supports sections, symbols, relocations, etc. That might be just as much work as just adding a BRIG emitter.</div><div><br class=""></div><div>Just a thought though.</div><div><br class=""></div><div>Cheers,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Cheers, <br class="">
Rafael </p>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></body></html>