- User Since
- Sep 8 2014, 1:20 PM (344 w, 12 h)
Tue, Mar 30
Is there a problem if both APIs are called (providing they don't conflict with each other or duplicate arguments?)
@steven_wu thanks for your review. Is this good to be merged then?
@steven_wu ping. thanks
Thu, Mar 25
@steven_wu please take a look when you have a chance. Thanks
Wed, Mar 24
renamed lto_codegen_debug_options_early to lto_set_debug_options, and add an entry to lto.exports
Mon, Mar 22
@steven_wu I've addressed your comment. Please review when you have a chance.
Fri, Mar 19
- use _array interface in lto_codegen_debug_options_early
- replace parsedOptionsEarly and parsedOptions with a single enum variable.
Thu, Mar 18
in this patch we add a new libLTO API to specify debug options independent of an lto_code_gen_t.
This allows clients to pass codegen flags (through libLTO) which otherwise today are ignored.
Sun, Mar 14
Mar 10 2021
Mar 9 2021
@daltenty provided a reduced testcase that would fail without this fix.
Mar 8 2021
@fhahn do you mean a negative test to make sure the assertion that got tripped in llvm/test/LTO/X86/remangle_intrinsics.ll does not happen anymore? Or test that llvm-lto delegates the relocation model property to the TargetMachine?
Feb 26 2021
Feb 25 2021
Dec 3 2020
Sep 26 2020
Thanks Steven and Teresa.
Sep 25 2020
@steven_wu what about the alternative solution where we make libLTO query the --filetype command line option. This will not require adding a new function to the API, but it does change the behavior of existing functions (lto_codegen_write_merged_modules, lto_codegen_compile, lto_codegen_optimize, lto_codegen_compile_optimized, lto_codegen_compile_to_file)
Sep 21 2020
Sep 16 2020
Teresa and Steven, thanks for the comments.
Aug 31 2020
Hi Teresa(@tejohnson ) and Peter (@pcc )
This is the patch for the C++ dynamic_cast optimization that I emailed llvm-dev in April and got a reply from Teresa.
ThinLTO enablement for this optimization is not implemented yet (sorry have been trying read on thinLTO and fix this but haven't had any time yet)
Will it be possible to do a round of review for the current implementation and add thinLTO support later?
Aug 14 2020
Jul 31 2020
Jul 30 2020
Jun 17 2020
this commit breaks the following testcase. If you agree this is a regression, then can you please revert your commit until this is addressed.
May 11 2020
Just to summarize. The testcase demonstrating the issue is added to llvm/unittests/Analysis/ScalarEvolutionTest.cpp.
The description of what the issue is, is in the "The problem" section in the description of this review.
The solution implemented in this review is to detect when an "incomplete" PHI is being createSCEV'ed and return a SCEVUnknown.
Feedback is greatly appreciated.
May 4 2020
gentle ping. Thanks
Apr 27 2020
gentle ping. Thanks
Apr 20 2020
gentle ping. Thanks
Apr 13 2020
Thanks Zheng !! Your testcase is indeed more focused on the exact issue in getSCEV.
I will wait to get more feedback on the correctness of the fix. Once it's decided that it's the correct fix, I will post an NFC review that adds your testcase with the "old behavior" expectations, and then this patch will amend the testcase.
Any chance this can get reviewed today. Thanks.
Apr 8 2020
unit test added
Apr 6 2020
Dec 9 2019
Hi Galina (@gkistanova ). This is just a friendly ping. Thanks.
Dec 3 2019
Nov 26 2019
Nov 25 2019
@gkistanova Hi Galina, I sent you an email on Thursday, November 21, 2019 requesting access for the new build bot.
Can you please confirm that you received it. Thanks.
Nov 21 2019
Hi Galina (@gkistanova), how do I get this patch into the zorg repo? Thanks
Oct 9 2019
Hi Vedant, thanks for the quick fix.
The test file works, and I'm able to patch it when I add more value profiles.
I think the comments should be rearranged like so (basically I fixed the placement of the Counter and Name sections):
// Header // // INSTR_PROF_RAW_HEADER(uint64_t, Magic, __llvm_profile_get_magic()) // INSTR_PROF_RAW_HEADER(uint64_t, Version, __llvm_profile_get_version()) // INSTR_PROF_RAW_HEADER(uint64_t, DataSize, DataSize) // INSTR_PROF_RAW_HEADER(uint64_t, CountersSize, CountersSize) // INSTR_PROF_RAW_HEADER(uint64_t, NamesSize, NamesSize) // INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin) // INSTR_PROF_RAW_HEADER(uint64_t, NamesDelta, (uintptr_t)NamesBegin) // INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
Hi @vsk can you provide a description/script on how to recreate the malformed-ptr-to-counter-array.profraw file when someone is changing the profile layout (for example by adding new value profiling kinds).
I'm thinking something like llvm/test/tools/llvm-profdata/raw-two-profiles.test would be nice
Oct 1 2019
Let me know what you think.
Sep 30 2019
Teresa and David, thanks for reviewing.
Rong Xu, I'll wait for your approval.
Sep 27 2019
- Renamed Plugin_t to PluginT, and checked that no other type name has an underscore.
- Renamed VPCPluginChain to PluginChain
Renamed ValueProfileOracle to ValueProfileCollector. I agree that at the moment, this utility class has a single purpose and that's to collect value profiling candidates; so the new name makes sense.
I enclosed the VPOPluginChain template class in an unnamed namespace so that all instantiated member functions (and constructors) get internal linkage rather than external weak, which will hopefully give more reason to inline them and eliminate their definitions. Thanks to Hubert Tong for this suggestion.
Sep 26 2019
Changed 'VPOPluginChain_t' to 'VPOPluginChainFinal` based on Teresa's comment.
Sep 23 2019
Sep 11 2019
Just FYI, that our (IBM's) internal bots are also breaking because the following tests are not cleaning the build/test/Reduce/tmp folder:
LLVM :: Reduce/remove-funcs.ll LLVM :: Reduce/remove-metadata.ll
And we're forced to sometimes do a clean build.