<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 25, 2014 at 5:01 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25 October 2014 10:02, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
> To clarify: Are you asking if there's a use case for clang being able to generate IR for architectures that it can't generate native code for?  The only cases I can think of for this are special targets (SPIR, PNaCl), where there isn't a corresponding back end.<br>
<br>
</span>If the only cases are the ones that don't have back-ends, then the<br>
solution is trivial: create empty back-ends for them that *just*<br>
contains the target information, and all should behave identical.<br></blockquote><div><br></div><div>I think this is OK for PNaCl.</div><div><br></div><div>What David is suggesting is interesting though: what if a target wanted to have ARM, x86 and MIPS assembly all assembled in a single executable at the end (not PNaCl's usecase)? It seems like you could just create separate .o and merge them later, no?</div></div></div></div>