<div dir="ltr">Committed as r230069.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 6:14 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Thu, Feb 19, 2015 at 5:50 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 19 February 2015 at 19:41, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>> wrote:<br>
> On Wed, Feb 11, 2015 at 4:37 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
>> I found that Writing and reading Native files from YAML reader is actually<br>
>> tricky. Readers generally don't need a linking context, but writers do. So<br>
>> it's not easy to call a writer from a reader. Seems it needs a plumbing<br>
>> work.<br>
>><br>
>> Then I tried to convert a YAML file to Native using yaml2obj -format=native.<br>
>> yaml2obj didn't actually support Native format because Native format lives<br>
>> only in LLD. Yet it's intended to be an alternative, hopefully better object<br>
>> file format, it's not supported by anyone except the linker. There's no<br>
>> consumer producing a file in that file format.<br>
><br>
> We haven't taught clang to produce it yet because the format isn't<br>
> finalized. The performance gain from it is still rather large, and I<br>
> feel it's an important feature.<br>
<br>
</span>Please note that we don't have evidence of this yet.<br>
<br>
I would be very opposed to adding a new file format to llvm proper until<br>
<br>
* lld is production quality<br>
* lld is as fast as gold on ELF<br>
* there is experimental evidence that a new format would make it even<br>
faster without compromising its ability to report errors.<br></blockquote><div><br></div></div></div><div>I agree with all the points. If we eventually think that we need a new file format for speed, the current native file format needs to be evaluated to see if it's suitable for that purpose, along with other points such as extendability of file format, complexity, etc.</div><div><br></div><div>For now let me go with this patch to unblock stuffs.</div><div><br></div><div>Thank you for reviewing.</div></div></div></div>
</blockquote></div><br></div>