Please do take over the pass revival. College hasn't left me with the bandwidth to continue this side project :) <div><br></div><div>If there's small things here and there, I'd be happy to pitch in. However,.whipping the patch into shape is beyond me right now.</div><div><br></div><div>Thanks</div><div>Siddharth <br><div dir="auto"><br><br><div class="gmail_quote"><div dir="ltr">On Fri 23 Mar, 2018, 00:53 via llvm-dev, <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
>> This work could also be used to fix [3]. Although this probably needs<br>
>> more though because there's the question of whether we should preserve<br>
>> existing debug information in an LLVM IR file or write over it when it<br>
>> is given to Clang.<br>
><br>
> If foo.ll contains edited debug info, `clang -g` shouldn't silently drop<br>
> the edits. A warning + no-op seems more appropriate.<br>
><br>
> Happy to help with code review!<br>
><br>
> thanks,<br>
> vedant<br>
<br>
Historically, the (mc) assembler has pretended the `-g` was not present<br>
and simply used the debug info described in the assembler source, with no<br>
diagnostic.  I think that would be reasonable behavior for `llvm-as -g`<br>
or `clang -g foo.ll` as well.<br>
--paulr<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sending this from my phone, please excuse any typos!</div></div>