- User Since
- Nov 4 2014, 3:46 PM (306 w, 4 d)
Wed, Sep 16
Fri, Sep 11
seems fine. The only worry is that if you have a stack that is close to the stack limit and the unwinder might just blow the stack away so it might have bincompat concerns.
Fri, Sep 4
Tue, Sep 1
Mon, Aug 31
I am a bit worry that linker might concatenate bitcode file with padding to achieve alignment requirement, etc. I guess you can create a termination block to mark the end but it is hard to seek the next start.
Fri, Aug 28
Sorry for the inconvenience that libunwind is not really buildable for armv7 from iOS SDK. You can build a single threaded version without referring to those interfaces. If this is really troublesome for you, feel free to file a bug report and we can see what can be done here.
Wed, Aug 26
Aug 17 2020
Aug 12 2020
Aug 7 2020
Also added a followup that can potentially deal with the conflict between "_$NAME" and "\01_$NAME". Not sure if that is going to affect some other platforms or not so I put them in a separate review: https://reviews.llvm.org/D85564
Address review feedback.
Aug 6 2020
Aug 5 2020
Change how the GUID is computed in ThinLTOCodeGenerator.
Jul 30 2020
Jul 28 2020
This is basically a fundamental issues in GUID for machO format, which I am not sure if we can fix the underlying issue. That requires computing GUID based on mangled name, which can be more expensive and I am not sure if it will break the module summary for compatibility if we switch algorithm. So I fixed the export/preserve list only because that is the only thing I can think of that will surface as a bug. Otherwise, the mismatch GUID will just be a missed optimization opportunity.
Jul 27 2020
I have seen that and was wondering why. Thanks for figuring that out!
Jul 23 2020
rebase the patch and ping.
Jul 22 2020
Address review feedback
Jul 20 2020
Address review feedback and also add a testcase to make sure good branch
weights are not stripped.
Jul 14 2020
Use Option::matches instead.
Jul 13 2020
Add comments in the tests.
Jun 30 2020
Jun 29 2020
Agree this is ugly but the clean up looks fine. Not sure how to write a test as well but I can see the @ file path is triggered correctly.
Jun 26 2020
Jun 25 2020
Jun 23 2020
Not sure if it makes more sense to break the patch into two commits:
- config.guess change is for building the correct host triple on apple silicon machine without explicitly specify it.
- the driver change is for better default on Apple silicon Mac.
Jun 22 2020
Jun 19 2020
Jun 2 2020
Apr 30 2020
Mar 10 2020
Mar 9 2020
It looks good in general. I would prefer to have two separate tests, one for upgrade, one for ir-linking.
Mar 5 2020
What is the goal for this option? Do you expect any users of this or this is for debugging WPD?
Feb 28 2020
Feb 26 2020
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.
Feb 25 2020
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.
Feb 24 2020
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.
Feb 20 2020
Feb 19 2020
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).
Feb 7 2020
I see. I don't really care then. LGTM!
Feb 6 2020
I hope we are not renaming everything because it add complexity on compatibility.
Feb 2 2020
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.
Feb 1 2020
Looks like this is an ABI change for WIN64. If that is intended then LGTM
Jan 30 2020
@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.
Jan 29 2020
Move static_assert into header