It looks good in general. I would prefer to have two separate tests, one for upgrade, one for ir-linking.

In D75617#1908254, @evgeny777 wrote:

What is the goal for this option? Do you expect any users of this or this is for debugging WPD?

It is for debugging. Not WPD itself but rather a devirtualized binary. See comment above

What is the goal for this option? Do you expect any users of this or this is for debugging WPD?

Thanks. LGTM. I will let @arphaman to approve this.

The 0x40 bit is actually OBJC_IMAGE_HAS_CATEGORY_CLASS_PROPERTIES, which probably can differ from translation unit to translation unit even within ObjC. Some of the other bits should not be different. That is why I say you can break the bits down even more if needed.

Clang seems to set it unconditionally. Presumably it just controls whether category descriptors have a class-properties field; offhand, I don't know why that would need to be set globally.

I agree with all of this except that I'm not sure there's any situation where ObjC and Swift translation units should be disagreeing about the ObjC-specific parts of the OBJC_IMAGE_INFO.

In D71219#1892292, @manmanren wrote:

We should add a new module flag (with type Error) that contains Major and Minor and make sure "Garbage Collection" value is the same for Swift as for ObjC.

In the backend, we will reconstruct IMAGE_INFO from the new module flags and make sure the value stays the same with and without this patch.

IMAGE_INFO will be different for Swift vs ObjC.

Should be question mark! Meant for clarification from @steven_wu and @rjmccall. Should IMAGE_INFO include the value from the new module flag?

In D74784#1891750, @dmajor wrote:

@steven_wu, ping, could you clarify about the tests please?

In D71219#1890444, @jinlin wrote:

In D71219#1791936, @steven_wu wrote:

1. I will add a llvm-link tests for combining objc and swift bitcode.
2. What do you mean by "codegen tests for correct value in the object file"? There is no "object file" in the picture. Are you asking for a test that checks the value in the output of llvm-link?

I think the decision was to break apart the current "Objective-C Garbage Collection" metadata. You need codegen test to test that OBJC_IMAGE_INFO is generated correctly after breaking apart the value.

I have question regarding this. Let's assume we have one assembly file from Objective-C and another one from Swift.

Objective-C assembly:
L_OBJC_IMAGE_INFO:

	.long	0
	.long	64

Swift assembly:

L_OBJC_IMAGE_INFO:

	.long	0
	.long	83953472

Let's assume that the llvm-link can link Swift bitcode and Objective-C bit successfully and the llc can generate the assembly for the merged output bitcode.

In the final assembly file, what value do you expect for L_OBJC_IMAGE_INFO?

In D74994#1889980, @sbc100 wrote:

In D74994#1889957, @steven_wu wrote:

I don't feel like this is necessary and creating a subdirectory without creating a new library feels weird. I agree the layout is a bit weird for new comer to LTO library but it is a relatively small hurdle. I don't exactly feel like I want to pay the cost of making git blame a bit harder.

Any other reason for changing the layout?

Just what I said in the comment. I'm not wedded to this change. Will drop it if others don't think it makes sense.

Out of interest do you know if there are plans to remove the legacy code one day?

I don't feel like this is necessary and creating a subdirectory without creating a new library feels weird. I agree the layout is a bit weird for new comer to LTO library but it is a relatively small hurdle. I don't exactly feel like I want to pay the cost of making git blame a bit harder.

ping

I forgot if there is reason to use the option by default at all time (I did ask that in the previous review but Alex might have given more context offline).

I see. I don't really care then. LGTM!

ping

In D73584#1862464, @zero9178 wrote:

In D73584#1862110, @steven_wu wrote:

I hope we are not renaming everything because it add complexity on compatibility.

Rename only the refs from libunwind is not enough since there are refs from clang header and libc++abi as well. unwind.h and corresponding header from clang are both shipping products which add compatibility problem.

Git grepping for __ personality_routine after the patch yields only three results. One is the typedef inside of the clang Headers, Two are inside of tests of llvm that I am not sure are relevant here. libc++abi uses the name _Unwind_Personality_Fn instead of __personality_routine that libunwind has used prior to this patch. _Unwind_Personality_Fn is also what GCC calls it. So this patch actually makes it possible to compile libc++abi with libunwind (Build errors only show up on windows since only windows has actually used _Unwind_Personality_Fn ).

Regarding compatibility I am not sure, but I thought users are expected to include unwind.h from clang Headers anyways.

I hope we are not renaming everything because it add complexity on compatibility.

The only case I know which can break after ABI change is the application has its own implementations to inspecting and handling exceptions. Almost everything go through libunwind and libcxxabi so as long as they are agree on the ABI, you have most of the cases covered.

I don't really mind either way. If you are using clang, you are really not expecting to use <unwind.h> in libunwind without going through the clang header, which has both versions defined.

Looks like this is an ABI change for WIN64. If that is intended then LGTM

@hans I landed this on master. Let me know if I need to do something for release branch. I will wait a bit to see if it breaks any unexpected users.

Move static_assert into header

It was updated locally on my side but I guess it won't reflected here. Updating.

Conditionalize the .private_extern based on VISIBILITY_HIDDEN macro

In D73577#1845550, @kledzik wrote:

Should there be a COMPILER_RT_ALIAS and COMPILER_RT_HIDDEN_ALIAS macro? Does this change effect the libcompiler_rt.dylib in the OS. In the dylib, I suspect the aliases should be global.

In D67678#1834957, @rsmith wrote:

In D67678#1834542, @steven_wu wrote:

@rsmith This also breaks macOS SDK. Can we revert this as we discuss a less aggressive option?

(This was already reverted a couple of days ago.)

Do you have a timeline for how long it would take to fix the MacOS SDK? Is this something we could realistically aim to do in Clang 11 instead? I would really prefer for us to not have different defaults for Darwin versus everywhere else, so if waiting one release cycle is enough, that seems fine.

I'll split out the new flag at least and re-land for Clang 10, while we figure out how to set the default.

@rsmith This also breaks macOS SDK. Can we revert this as we discuss a less aggressive option?

Fix ARM_EHABI.

In D72543#1825496, @smeenai wrote:

In D72543#1825454, @rjmccall wrote:

In D72543#1825422, @smeenai wrote:

In D72543#1825178, @rjmccall wrote:

In D72543#1825150, @smeenai wrote:

From spelunking through history, it looks like D33030 tried to solve the same problem, and then rL319123 undid that solution and came up with a different one to solve the same underlying issue. rL319123 is still in place; does it need to be adjusted for the change in this diff?

It looks like those patches were attempts to ensure adequate alignment of the exception object given the absence of an alignment attribute on the _Unwind_Exception type itself. rL319123 became inadequate after _Unwind_Exception became an aligned type because that change still affected the layout of the C++ exception types. What we're fixing here is essentially the same problem that was introduced by D33030.

Makes sense. Should rL319123 be reverted then? The extra space that's being allocated by that change doesn't do what it's meant to do, so it seems wasteful to keep allocating it.

If __cxa_exception is already sufficiently aligned, I believe that patch does not allocate any extra space.

You're right; I understand the case rL319123 was intended for now.

1. I will add a llvm-link tests for combining objc and swift bitcode.
2. What do you mean by "codegen tests for correct value in the object file"? There is no "object file" in the picture. Are you asking for a test that checks the value in the output of llvm-link?

Commited in: 9366397f057d18401e680b2cb28a0ee17c59d4a6

In D69893#1786222, @kamleshbhalui wrote:

In D69893#1786202, @steven_wu wrote:

The fix LGTM. Do you have a reproducer that can be used as a test case? We should really add more tests for libunwind.

I currently do not have a reproducer test case for this.

LLVM LTO part LGTM. I will get another pair of eyes on lld changes.

SGTM.

This sounds like a good idea. Have you thought about just write out upgraded bitcode file on disk (since you named it a "SymTabCache"), maybe into thinLTO cache? This will speed up the incremental build as well. I think most of the upgrade path are coming from linking a bitcode static library, which is probably not changing during incremental build so we just need to upgrade once.

The fix LGTM. Do you have a reproducer that can be used as a testcase? We should really add more tests for libunwind.

Address review feedback

Breaking part the meta data sounds like a good idea. You will probably need to combine the value in the backend to generate the field in the object file.

Thanks for increasing test coverage. One comment in line.

Ah, I miss your fix. The fix LGTM.

LGTM!

LGTM

In D70404#1755124, @evgeny777 wrote:

I reimplemented the patch, now using extra 'Constant' attribute in GlobalVarSummary.

The goal is to allow importing of constants, which are not being detected as 'ReadOnly'. Such constants are imported with available_externally linkage, still allowing compiler to make some optimizations along the way.

In D70397#1753789, @miyuki wrote:

In D70397#1753767, @steven_wu wrote:

In this patch, add another stack frame completely defeat the purpose of assert(unw_step(&cursor) > 0);.

Is the DWARF unwinder supposed to be always able to step out of main()?

In D70397#1753428, @broadwaylamb wrote:

This test won't compile for ARM Linux (using ARM EHABI), I get the error this directive must appear between .cfi_startproc and .cfi_endproc directives.

LGTM with one nitpick.

Fix comments

Address review feedback

ping

LGTM

I think this is probably the best fix I can think as well. Agree with Teresa says, please add comments for reasons why it is implemented this way.

LGTM.

I can see why this is a good idea, but do you have numbers for this optimization? How much code can be inlined? Benchmark for speedup? code size? compile time impact?

LGTM.

ccache does not have the support for this, I am just saying that this can be easily implemented in ccache and that would be much better than the proposed solution here.

In D69327#1719411, @ychen wrote:

Thanks for the inputs @steven_wu @tejohnson. Totally agree with the points you brought up. One last thing I'm not quite sure is the caching of -fthin-link-bitcode. It is a -cc1 option since it is a kind of implementation of ThinLTO, right? I'm a little hesitant to begin writing up patches to teach build system/caching tool (I could think of at least three for our workload) to recognize this option because of that. If there are any changes to the option, the same thing needs to be done again. Do you have any thoughts on that? Is the option in use for your workload and do you think it is stable enough to have build systems caching for it? (Another option is to produce -fthin-link-bitcode output post compile time which I assume having total build time impact to some degree).

LGTM

Can you clarify what do you mean by 'waste time optimizing a file that finally hit the object file cache'?

That is not exactly what I meant. I meant:

LGTM. Thanks!

In D69107#1714175, @evgeny777 wrote:

From https://llvm.org/docs/LangRef.html#comdats :

Comdats have a name which represents the COMDAT key. All global objects that specify this key will only end up in the final object file if the linker chooses that key over some other key

To enforce this LLVM internalize pass doesn't internalize entire COMDAT group if any of its members should be preserved (see shouldPreserveGV). At the moment we can internalize global
in llvm::thinLTOResolvePrevailingInModule without looking at other COMDAT group members and break this guarantee