- User Since
- Dec 15 2015, 10:55 AM (277 w, 4 d)
Jan 21 2021
Jan 20 2021
Thanks again for the comments. I've modified the test to use -NEXT as
Jan 19 2021
Since D94962 was landed, we don't need this one anymore.
Jan 15 2021
implemented MaskRay's suggestions, added tests
also removed unused Format.h include
removed now unused <algorithm>
Indeed, there are not that many output sections. I simplified the code
by removing the sorting and formatting.
Jan 14 2021
Can we not just make -gsplit-dwarf set the DwarfFissionKind without also looking at other things? That way, we don't have to worry about detecting the right mix of -g, -g2, -fthinlto-index, -x ir, bitcode input, etc. If there is some reason why this doesn't work, I would also like it to be expressed in a comment in the code so that someone doesn't come along and simplify/break the code later on.
Thanks for the comments!
Jan 13 2021
For Chrome on Chrome OS, this is https://crbug.com/1158215
As for the specific alternatives you suggested:
Jan 12 2021
Jun 5 2020
Ok, thanks for clarifying.
Jun 4 2020
Apr 16 2020
Apr 13 2020
@pcc, do you have time for another look?
Apr 8 2020
Thanks, Peter! I've implemented your suggestions.
@pcc, do you have time to take a look?
Apr 6 2020
@tejohnson: The defs look like
Apr 3 2020
Added a comment to (hopefully) better explain what the test does.
@dblaikie: My understanding is that LLVM reserves the right to assume that distinct globals never alias and optimize based on that (e.g. as mentioned under https://releases.llvm.org/10.0.0/docs/AliasAnalysis.html#the-basicaa-pass), and that declaring globals as zero-sized is the accepted way to avoid that (e.g. as mentioned in https://bugs.llvm.org/show_bug.cgi?id=31675#c5).
Dec 5 2019
Dec 3 2019
added test that fails without the revert
Dec 2 2019
Or just avoid sinking for these cases and do not generate llvm.assume calls.
It seems we have a variety of opinions on the right way to avoid the problem here, and many of them seem to require a fair bit of work. I'm all for getting to better semantics that avoid the problem we're seeing, but agreeing on a course of action, making the changes, testing it, and reviewing it seems like it would take a while. Meanwhile, we have a compiler that miscompiles cout << -10.0; Any chance we can get this change in to stop that from happening while we work on a better fix?
Nov 27 2019
How was DAE able to replace an argument with undef which was fed to strlen? Is that the real bug?
Responding to @jdoerfert's comments:
Nov 26 2019
moved undef check above other if statement
Oct 25 2019
I'm assuming that addGetSourcecodeSteps takes care of checking out the correct revision. From a cursory look at LLVMBuildFactory and the Buildbot documentation, this appears to be the case.
Sep 26 2019
Sep 25 2019
Sep 24 2019
Thanks! Removing unnecessary llvm:: prefix before commit.
@ruiu's comments (thanks!)
Sep 20 2019
@MaskRay's comments. Thanks! I've changed the original code to match.
Sep 19 2019
Sep 13 2019
Sep 12 2019
The help text for -start-lib and -end-lib matches that in the ELF linker. Please keep those matching by changing it there, too. Also, I think s/library/archive/, so that it matches the naming of -wholearchive.
Sep 3 2019
Aug 30 2019
Implemented ruiu's requests before committing. Thanks for reviewing!
Aug 29 2019
- allow mixing -start-lib and -wholearchive:
Aug 28 2019
- made AddMode an enum class
- simplified AddMode computation in OPT_INPUT case
- added missing std::moves
- use auto instead of explicitly naming LazyArchive
Aug 27 2019
Primarily, this change adds a LazyObject Symbol kind, and a LazyObjFile InputFile kind. A LazyObject represents a symbol defined in a LazyObjFile, and a LazyObjFile is either a native object file or a bitcode file that we know of, but have not yet decided to link in. As with the LazyArchive symbols we already had, when we encounter both a lazy symbol and an Undefined symbol, we resolve this by linking in the file that defines the symbol, so the result is a Defined symbol.
fix places where I needed to add handling of LazyObject symbols
Seeing the code here, I see I still need to handle LazyObject in symbol resolution.
Aug 26 2019
@ruiu, I'd like your opinion on this.
Related bug: https://bugs.llvm.org/show_bug.cgi?id=42717
Aug 21 2019
Aug 16 2019
changed flag name to -lto-obj-path:
Aug 12 2019
Landed in r368612 / d47622.
'll call the Config field ltoObjPath, same as in the ELF linker.
After discussion in person, we decided on -lto-obj-path: similar to the naming in the ELF linker, and we'
@rnk, what do you think of the name I proposed?
Aug 9 2019
Aug 8 2019
In ELF, the config name is ltoObjPath, and the flag is -plugin-opt=obj-path=