<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank" class="cremed">stoklund@2pi.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Jun 26, 2013, at 4:18 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="cremed">echristo@gmail.com</a>> wrote:<br>

<br>
> So inverting it so that MI contains LLVM IR instead of the other way<br>
> around? Then we'd need a serialization format for MI that happened to<br>
> include a way of serializing LLVM IR within. From a quick "hey, this<br>
> seems reasonable" the idea of embedding the MI into the IR rather than<br>
> the other way around seems to make sense since we have already have<br>
> code to serialize the IR.<br>
<br>
</div>I’d suggest something based on YAML which would allow you to include IR verbatim just by indenting it.<br></blockquote><div><br></div><div>We can also use YAML embedded inside IR, potentially using the string syntax Dan proposed or any other number of embedding mechanisms.</div>
<div><br></div><div>I like using YAML to represent the somewhat arbitrary datastructures of MI so that we don't spend a lot of time inventing clever syntax for something that has much more limited uses than the actual IR. I haven't heard anyone really object to it.</div>
<div><br></div><div>However, I do think it's an open question as to whether to embed IR in a MI container, or MI in an IR container. A few observations:</div><div><br></div><div>- No one has pointed out any really fundamental *problems* with any of the approaches. I think both approaches can be made to work with reasonable amounts of effort, and neither has really fundamental design problems.</div>
<div><br></div><div>- Different use cases will be more or less easy to write in different forms. For example, Jakob's point:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The IR module should be optional when serializing MI. The back-pointers from MI to IR are not required, and I can imagine many useful test cases that won’t need them.</blockquote></div><div class="gmail_extra"><br></div>
I've heard Dan and others say exactly the opposite -- that MI should be optional. I suspect that some test cases are more MI focused, and some are less. But I don't see either being optional as a hard prerequisite.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So, here is my concrete suggestion: if all of these approaches seem to work and there aren't huge downsides but only reasonable tradeoffs, let the folks writing the patches make the decision. At the moment that appears to be Dan and maybe Bob. Is there a reason to not let them pick the design they want to make forward progress with and run with it? I think that will be much more productive and get us back to the important part: testing MI-level passes.</div>
<div class="gmail_extra"><br></div></div>