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

[Duncan P. N. Exon Smith]

> 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.

> 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.  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.

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.

> 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 --------------
A non-text attachment was scrubbed...
Name: 0001-Don-t-upgrade-global-constructors-when-reading-bit-2.patch
Type: application/octet-stream
Size: 10410 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140811/18bda56a/attachment.obj>