- User Since
- Sep 8 2014, 1:20 PM (314 w, 4 d)
Wed, Sep 16
Teresa and Steven, thanks for the comments.
Mon, Aug 31
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.