<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-04-29 11:40 GMT-07:00 Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2015-Apr-29, at 06:40, Krzysztof Parzyszek <<a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a>> wrote:<br>
><br>
> On 4/28/2015 7:13 PM, Alex L wrote:<br>
>><br>
>><br>
>> 2015-04-28 16:26 GMT-07:00 Matthias Braun <<a href="mailto:matze@braunis.de">matze@braunis.de</a><br>
>> <mailto:<a href="mailto:matze@braunis.de">matze@braunis.de</a>>>:<br>
>><br>
>>    For that use case it is worth keeping the following things in mind:<br>
>>    - Please try to keep the output of the various dump functions, esp.<br>
>>    MachineInstr::dump(), MachineOperand::dump(),<br>
>>    MachineBasicBlock::dump() as close as possible to the format you use<br>
>>    for serializing.<br>
>> [...]<br>
>><br>
>> Ideally the new syntax would replace the existing print/dump syntax. The<br>
>> new syntax will lead to certain missing information when<br>
>> this information can be inferred (e.g. the TiedTo and IsEarlyClobber<br>
>> attributes for register operands that I mentioned earlier in this thread),<br>
>> so maybe we could have some sort of verbose dumping option where<br>
>> absolutely everything is dumped.<br>
><br>
><br>
> I think that the new syntax is less readable than the current format of the "dump" functions, and in the long term it would be better to have something more human-friendly.  However, using YAML has the advantage that it's easier to parse it than the direct output of "dump" and so it will take less time to implement a YAML-based solution.  My concern is that you may run out of time to complete this and the file format is not the most important thing in this project.  Getting it to work, if only as a proof of concept, would be very helpful to everyone.  Coming up with a fancier grammar and implementing a parser for it could be done later on top of the initial implementation.<br>
><br>
> -Krzysztof<br>
<br>
</span>Until I got to this email, I was opposed to using YAML here -- I'd<br>
prefer a custom grammar and parser -- but I find Krzysztof's point<br>
here pretty convincing.<br>
<br>
Starting with a (hybrid) YAML representation seems like a reasonable<br>
way to bootstrap a machine IR.  Once it's in place and working, we<br>
can come back and strip away the YAML parts until it's human-<br>
friendly.  (And since YAML is machine-friendly, upgrade scripts for<br>
testcases should be straightforward.)<br></blockquote><div><br></div><div>I think that this would be a good approach.</div><div>I will work on the proposed YAML hybrid format for now and will begin</div><div>sending out the patches soon. Once it's working, people can evaluate it</div><div>for themselves and see if it suits them or if we need to change it to a custom format.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
BTW, we probably need some sort of LangRef document for this.  Maybe<br>
docs/MIRLangRef.rst?</blockquote><div><br></div><div>That's fine with me.</div><div><br></div><div>Alex </div></div></div></div>