[PATCH] Don't upgrade global constructors when reading bitcode

[Nick Lewycky]

On 11 August 2014 19:13, Duncan P. N. Exon Smith <dexonsmith at apple.com>
wrote:

>
> > On 2014-Aug-11, at 17:21, Nick Lewycky <nlewycky at google.com> wrote:
> >
> >> IMO, writing to bitcode and reading back shouldn't change the IR.
> >
> > It doesn't if you have current IR.
>
> Actually, it does!  That's the problem.  The two-field version is valid,
> current IR (it's even the default in the C++ API), but round-tripping to
> bitcode changes it to the three-field version.
>

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.

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?

> Even llvm 1.x did IR auto-upgrading. Sorry, but [...]
>
> [snip]
>
> I think we're on the same page here.  I was unclear.
>
> *Assuming your IR is current*, IR shouldn't change if you serialize to
> bitcode.  Old IR obviously has to be upgraded.
>
> >> Does the plan in PR20506 sound reasonable?
> >
> > 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.
>
> I guess I'm conservative, but I feel like C API users might be using
> global constructors and might care.


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.


>  I can send a post to llvmdev later
> this week to get things moving with PR20506, and if no one responds
> after a couple of weeks, I'm happy to expedite it.


That's fine, I don't feel any need to expedite it.


> Either way, are you comfortable with the updated patch?  I still see it
> as an improvement over ToT, and it unblocks my use-list order work.
>

Yep, got it. Go right ahead.

> 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.
>
> Heh, lots of fun :).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140811/d2cac641/attachment.html>