<div dir="ltr">I forget tmhe details exactly (like I said, drowning in too many threads, emails, etc) - but my preference was to make the number match whatever ends up int he DWARF. I think we're reasonably moving towards an eventual future where we might be able to generate type descriptions in the frontend and have the backend/middle end completely agnostic of that blob.<br><br>Changing the semantics of the field is tricky, yes - though we can rev the bitcode version. Might not be worth it.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 4, 2016 at 9:47 AM Victor Leschuk <<a href="mailto:vleschuk@accesssoftek.com">vleschuk@accesssoftek.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">vleschuk added inline comments.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> aprantl wrote in DIBuilder.h:139<br class="gmail_msg">
> What is the motivation to change this to bytes? This kind of API change looks dangerous to me because frontends won't even get a type error to notify them that the API has changed.<br class="gmail_msg">
<br class="gmail_msg">
Hmm, yep, I think you are right. I thought it would be better to pass bytes from frontend to backend as frontend has special CharUnits class for this purpose, however such changes in API can affect another frontends. Will change it back to bits and convert in backend.<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D24425" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D24425</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>