- User Since
- Nov 4 2014, 3:46 PM (345 w, 6 d)
Tue, Jun 15
Tue, Jun 8
Wed, Jun 2
Can you create a new test for clang Driver instead of rewrite the cc1 test?
Mon, May 24
Sat, May 22
Just saw this. Thanks for taking care of the fallout.
May 20 2021
May 19 2021
Remove all incompatible attributes.
Address review feedback. Now remove all incompatible attributes from non pointer type.
May 18 2021
I don't think current implementation is the best idea. I think is better to make the gcc compatible LTO value to be a clang Driver only option, give them an option name, and handle them separately in driver to invoke correct fullLTO cc1 command, so that:
- The value remain invalid option for cc1 (CompilerInvocation should just error on that, just like now).
- The ignored value should not appear in the help or autocompletion.
May 17 2021
The reason I only fix return type in D102201 is that I identify the source of such incompatibility, which is coming from an optimization pass, so that can be wild spread incompatibility. The optimization pass explicitly happens when it is return type and check to remove all attributes that is incompatibly returned from typeIncompatible.
That is easier than I think. Is there still any missing function in terms of NewPM after this patch?
May 15 2021
I don’t understand code size increase as well and have no guess about what might happen. This should be noop on bitcode that can pass the verifier.
May 11 2021
May 10 2021
Address review feedback.
Apr 29 2021
Apr 27 2021
A bit more information is that the GV that triggers the assertion now is being materialized from both Global and Local (Indirect?) Materializer because of the complexity of the GV and Alias in the module.
Apr 26 2021
Ping. I still couldn't figure the algorithm used here and what semantics does the comdat have. Need some help here.
Apr 13 2021
Mar 30 2021
Ok, fine with that.
FYI, for the broken comdat, see the unit tests breaks
Mar 29 2021
@pcc @tejohnson I tried to fix the assertion failure shown in the test case (reduced from actual code generated from swift compiler) by simplifying the ValueMapper but I couldn't quite get the comdat tests to pass. I think comdat is relying on some of the indirect symbol that doesn't appear in the ValueMap for the normal context but I couldn't quite figure out how that works. Any suggestion?
Mar 22 2021
I still don't like this implementation, but fine if you have to do this.
Mar 19 2021
Like replied in email. The non-scaleable option is very intentional and debug_option is by its name for compiler developer only and should not be used in production. The preferred option is to create API to set every single attributes you want to set.
Mar 17 2021
Mar 16 2021
Mar 8 2021
Can you add a test case? Otherwise, LGTM.
LTOCodegen can achieve most of the temp file by going through write_merged_module function. While I don't see this save-temps gains much advantage comparing the existing one except more granularity, it is also fine to have this new debug option. It would be good to switch the save-temp interface to using this flag in the future since it will simplify the code in libLTO and ld.
Feb 23 2021
This one might be better just fix the FIXME in linkCombinedIndex since assert won't do anything in the release build.
Feb 19 2021
My main concern is just that weak alias for libc++abi that never worked for Darwin :)
Feb 18 2021
Feb 17 2021
Looks good. with a small comment inline.
Feb 16 2021
Good in general. Suggestions in line.
Feb 5 2021
Jan 29 2021
This looks clean. LGTM. ThinLTO change in a separate commit?
LGTM with only one comment.
Jan 27 2021
LGTM. @pcc does this look fine to you?
Jan 26 2021
Offline comment to Florian is that:
Jan 22 2021
MergedModule is needed to support legacy API lto_codegen_write_merged_modules. You don't technical get the module back in memory, you just need to write to a file.
Jan 21 2021
Looks good now. Thanks.
LGTM. Did you figure out the answer of your inline comment?
Jan 15 2021
Sounds like a good idea to me!
Jan 13 2021
Jan 12 2021
LGTM with a small comment.
I think this is good to be a first step. The approach is correct and left some small suggestion above. The linter warnings need to be fixed as well.
Dec 7 2020
Feedback has been provided on the mailing list. Using function attributes is preferred and changing legacy C API is not allowed.
Oct 16 2020
Oct 9 2020
Sep 25 2020
In that case, please increment LTO_API_VERSION. If you think the API needs more documentation, please add to docs/LinkTimeOptimization.rst
Note libLTO API needs to be stable so:
- If you need to add API, you need to bump API version, etc. Please refer to other commits that add APIs to see what needs to be done.
- If this is just a temporary workaround, I would resist make this change to bake in this API that will not be used in the future.
Can you clarify your motivation for this? libLTO is used as an interface for linker and linkers, in general, do not understand assembly files.
Sep 23 2020
Sep 22 2020
Ok, I guess we are on the same page. The idea sounds fine to me.
I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context?
Sep 16 2020
Sep 11 2020
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.
Sep 4 2020
Sep 1 2020
Aug 31 2020
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.
Aug 28 2020
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.
Aug 26 2020