- User Since
- Oct 27 2019, 11:03 AM (84 w, 5 d)
Tue, Jun 8
Tue, Jun 1
Thanks for all of the effort! On our downstream Cortex-R5 compiler, I'm seeing a 20.4% speedup on Coremark with this patch, which is good, however, the older patch (https://reviews.llvm.org/D88307) gave me a 21.6% speedup. Any idea what could account for the difference there?
Tue, May 18
OK, I will revert that commit on the 12.x branch then. Can you please file a bug for this patch and mark it as blocker of the release-12.0.1 metabug? I typically review and try to get an ack from at least on other person before backporting patches.
May 11 2021
May 10 2021
Mar 10 2021
Hello! I am seeing a downstream build failure on Mac as a result of your changes:
Mar 8 2021
We also encounter a build failure on the Mac related to above but in a different file:
clang/lib/CodeGen/CGStmtOpenMP.cpp:1916:3: error: too few template arguments for class template 'SmallVector'
SmallVector<llvm::Value *> EffectiveArgs;
clang/include/clang/Basic/LLVM.h:35:42: note: template is declared here
template<typename T, unsigned N> class SmallVector;
Jan 12 2021
Jan 7 2021
Jan 5 2021
Dec 23 2020
Dec 11 2020
Diff after rebase.
Dec 2 2020
Nov 29 2020
I can fix this locally to get our builds running, but is it possible that you could commit a fix upstream? I appreciate it, thanks!
Nov 27 2020
In the description, you refer to fallback_malloc.cpp "The code in libcxxabi/src/fallback_malloc.cpp looks like it could be simplified after this change -- I purposefully did not simplify it further to keep this change as straightforward as possible, since it is touching very important parts of the library."
Nov 23 2020
Looks like _LIBCPP_HAS_NO_THREADS is being set for libcxxabi, and the build now fails with this change:
Bump format version and add preliminary documentation for CoverageMappingFormat, SourceBasedCodeCoverage, and llvm-cov tool
Nov 19 2020
Just checking in again -- is there interest in completing this review? I'd be happy to assist, or I could post an updated version of it.
Oct 19 2020
@eastig I tried this experimental patch in our system, and it definitely brings highly significant improvement to coremark. When do you expect to post a version for reviewing -- what will the differences be?
Oct 8 2020
Oct 3 2020
1.) Fix a defect in the CGExprScalar.cpp code to instrument RHS condition for branch coverage that resulted in a RHS condition as being evaluated twice. This is incorrect behavior since a condition may have side-effects. I also added a test.
2.) Back out unintended whitespace/punctuation (please let me know if I overlooked anything).
3.) Rebase against updated upstream.
Sep 29 2020
Sep 17 2020
There exist downstream ARM compilers that doesn't support ARM64 and fail with Inputs/arm_function_name.ll. You should consider guarding arm64 specific tests.
Sep 7 2020
- Rename isLeafCondition() to isInstrumentedCondition() and rephrase associated comments
- Add branch regions on C++ range-based loops
Aug 24 2020
I just ran into what I think may be the same issue here in that llvm-objdump seems to ignore machine data (endian, possible mode) when disassembling ARM instructions on ARMv7. Is there any interest in completing this review and committing this particular fix (and making sure it works for ARMv7 as well)?
Aug 23 2020
Updating for formatting and comments (and some test adjustments after rebase). Bypassing logical-NOT operators in CodeGenFunction::isLeafCondition(), which checks the condition for the presence of logical-AND and logical-OR. (this can be further expanded, if necessary)
Aug 7 2020
Jul 31 2020
Thank you for your comments on the review! I will respond soon; also have been swamped this week.
Jul 27 2020
Jul 23 2020
Jul 15 2020
May 31 2020
It looks like clang/test/Profile/Inputs/c-general.profdata.v5 is being read as v6 rather than v5. Can you double check?
May 28 2020
clang/test/CodeGen/sanitize-coverage.c is also failing our downstream embedded ARMv7 validations.
Jan 21 2020
This test is still failing on the arm bots and also with my downstream ARM compiler validation.
Jan 17 2020
Hello! Your test specifically looks for "248", which is failing with my downstream embedded ARM compiler (we produce "249"); other similar tests that I've looked at simply ignore this value. Is there a reason why you need to check it specifically?
Jan 10 2020
Sorry, we just saw your commit to fix. We are OK. Thanks!
We maintain a downstream embedded ARM compiler, and this test is failing for us now because it assumes a 64bit size_t in the first CHECK line of the mempcpy-libcall.c. Because this is testing a GNU specific builtin, should it be specific to only targets that support that? Or should it be extended to support 32bit size_t?