Test for corner-cases in mul_overflow.pass.cpp#9792
Conversation
|
@fbusato if you agree with the approach, can you run |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesMultiply overflow test coverage
Assessment against linked issues
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
libcudacxx/test/libcudacxx/cuda/numeric/overflow.arithmetic/mul_overflow.pass.cpp (2)
110-130: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winsuggestion: Add an explicit fixed-width-integer header for the new aliases and use the
cuda::stdaliases required by this test suite. These lines currently rely on transitive exposure ofint8_t,int32_t,int64_t,uint32_t, anduint64_t. As per coding guidelines, include all headers needed by used symbols and do not rely on transitive includes.Source: Coding guidelines
133-133: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winsuggestion: Declare
uint128_maxasconstexpr; its initializer is compile-time evaluable. As per coding guidelines, compile-time-evaluable variables must beconstexpr.Source: Coding guidelines
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: e1e97b45-bf14-4c29-9e0a-f5bb7f5ca52e
📒 Files selected for processing (1)
libcudacxx/test/libcudacxx/cuda/numeric/overflow.arithmetic/mul_overflow.pass.cpp
|
/ok to test ece8939 |
😬 CI Workflow Results🟥 Finished in 2h 11m: Pass: 97%/71 | Total: 2d 01h | Max: 1h 59m | Hits: 99%/328843See results here. |
|
Although the test failures themselves do not seem to be related to this PR, I actually found that there is a slowdown! This is from libcu++ nvcc GCC / [CTK13.3 GCC15 C++17] Build(amd64) log: However, with other runs I have noticed that the slowest tests very quite a bit. Here are two random ones I pulled up: |
|
Great news; I am finding that this behavior might actually be completely expected, and that the kernels are being cached. I can deterministically get the slowdown by making sure the compiler has not come across the With that being said, merging this now would make the |
Description
While working on optimizing
mul_overflowkernel to resolve #7739, I have been using a local test-suite to catch corner-cases to ensure I don't introduce any regressions. For some odd reason, I am finding that when I added the tests tomul_overflow.pass.cppin the other PR, I'd see an atrocious execution time:This PR (and CI run results) would assure me that the slow times are truly local in scope, while making sure that the current version of
mul_overflowcovers all corner-cases.I also added
test_corner_casesbelowtest_exhaustivesince I didn't want to have it called repeatedly (especially because I'm explicitly controlling types to test the corner cases).Checklist