<div dir="ltr">On Fri, Dec 15, 2017 at 11:09 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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"><span class="">On Fri, Dec 15, 2017 at 11:07 AM, Saleem Abdulrasool via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>compnerd added inline comments.<br>
<br>
<br>
================<br>
</span><span>Comment at: test/Feature/elf-linker-option<wbr>s.ll:6<br>
+<br>
+!0 = !{!"spaced", !"option"}<br>
+!1 = !{!"nospace"}<br>
</span><span>----------------<br>
compnerd wrote:<br>
> jhenderson wrote:<br>
</span><span>> > ruiu wrote:<br>
> > > Imagine that these two strings are pathnames.  Pathnames can contain any character other than \0. That mean you can't distinguish "spaced options" from "spaced" and "options, which is bad. You should allow only one string.<br>
> > The way I see it, this is intended to be interpreted as a single option. However, I think this demonstrates why a key-value pair is important.<br>
> Yes, this is a single value.  " spaced option".  I don't remember what the issue was with trying to merge the entire spaced option into a single string.  But, that would simplify the logic here.  I think that we should go ahead and expect that the frontend will generate a single entry for that.  The key/value wouldn't help with this if the spaces were removed in the MDNode itself.<br>
</span>Wait, I forgot that I modelled this after the existing MachO and COFF behaviors.  I think that changing the behavior of this documented interface is less desirable.  If we want to have a new way to pass along the options, that is fine, but should be a separate change that unifies the behavior across all three object file formats.</blockquote><div><br></div></span><div>I don't think we should mimic an interface that could produce ambiguous string. If you think these interfaces need to be coherent all the time, please fix MachO and COFF models first</div></div></div></div></blockquote><div><br></div><div>I understand that you are concerned about the parsing of the options in the linker.  I think that the issue that you are raising is better addressed in the frontend rather than in the backend.  This is purely the passthru from the frontend to the backend, and I don't see why the LLVM IR needs to be modified for that as it can support either approach.</div><div> </div><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"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2804148766758391959HOEnZb"><div class="m_2804148766758391959h5">
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D40849" rel="noreferrer" target="_blank">https://reviews.llvm.org/D4084<wbr>9</a><br>
<br>
<br>
<br>
</div></div></blockquote></span></div></div></div></blockquote></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>