<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 August 2014 19:13, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> On 2014-Aug-11, at 17:21, Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br>
><br>
>> IMO, writing to bitcode and reading back shouldn't change the IR.<br>
><br>
> It doesn't if you have current IR.<br>
<br>
</div>Actually, it does!  That's the problem.  The two-field version is valid,<br>
current IR (it's even the default in the C++ API), but round-tripping to<br>
bitcode changes it to the three-field version.<br></blockquote><div><br></div><div>Ahh! Okay, usually what we do is just cold turkey update from old form to new form, and the old form fails the verifier and gets auto-upgraded when read.</div>

<div><br></div><div>I don't know what that wouldn't work in this case. Perhaps because we wanted to have a slow transition to the new form because of C API users?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> Even llvm 1.x did IR auto-upgrading. Sorry, but [...]<br>
<br>
[snip]<br>
<br>
I think we're on the same page here.  I was unclear.<br>
<br>
*Assuming your IR is current*, IR shouldn't change if you serialize to<br>
bitcode.  Old IR obviously has to be upgraded.<br>
<div class=""><br>
>> Does the plan in PR20506 sound reasonable?<br>
><br>
> Sounds reasonable to me, what it describes is an ABI break in slow motion with notices and stuff. I'm not sure we have any ABI users who *actually care* which is why I think it's better to move quickly (before we grow any users who do care *and* start relying on the deprecated behaviour), but I'm happy to let you want to handle this however you like.<br>


<br>
</div>I guess I'm conservative, but I feel like C API users might be using<br>
global constructors and might care.</blockquote><div><br></div><div>As far as I'm aware, this is the first time we've bothered. Normally we just silently break the C API, unless it's libLTO or libIndex -- those were designed to be able to keep working as we change LLVM and Clang. LLVMGetNumOperands et al were not.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I can send a post to llvmdev later<br>
this week to get things moving with PR20506, and if no one responds<br>
after a couple of weeks, I'm happy to expedite it.</blockquote><div><br></div><div>That's fine, I don't feel any need to expedite it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Either way, are you comfortable with the updated patch?  I still see it<br>
as an improvement over ToT, and it unblocks my use-list order work.<br></blockquote><div><br></div><div>Yep, got it. Go right ahead.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="">> Got it. I missed that this was about bitcode use list ordering work. Thanks for working on that, by the way! Gnarly problem. Covered in barnacles.<br>
<br>
</div>Heh, lots of fun :).<br>
<br>
</blockquote></div><br></div></div>