In places where MaxNumPromotions is used to allocated an array, bail out early to prevent allocating an array of length 0.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
+Rong and Wenlei based on history but let me know if there are suggested reviewers!
Also if it makes sense to add a test I'd be glad to!
Is there a test triggering the zero-length code path? It's valid to allocate an array of length zero. The code just cannot dereference the pointer.
Is there a test triggering the zero-length code path?
The context is that, I try to set sample-profile-icp-max-prom to zero (with the goal of evaluating how much ICP helps), and the compilation hangs without completion (and triggers timeout in crosstool)
By bootstrapping compiler w/ this patch, the build completed (I didn't verify the generated binary though)
btw I cc'ed you in an internal email with pointers to artifacts.
It's valid to allocate an array of length zero. The code just cannot dereference the pointer.
[1] said it's not ok for c / c++ to allocate a fixed size array of size 0 yet [2] mentions that allocating is ok but de-referencing is not..
It seems to me that the exact support differs from compiler to complier though. I'm not fluent in identifying to the relevant implementations, but maybe adding logs in the locally-boostrapped compiler helps (in the internal context)
[1] https://stackoverflow.com/questions/9722632/what-happens-if-i-define-a-0-size-array-in-c-c/9723093
[2] https://stackoverflow.com/questions/1087042/c-new-int0-will-it-allocate-memory
I think the reason MaxNumPromotion==0 breaks is likely the 0 size array think (like MaskRay mentioned).
Explicitly checking of 0 is a good fix here.
LGTM except I'm not sure if the second check is needed.
llvm/lib/Transforms/IPO/SampleProfile.cpp | ||
---|---|---|
846 | Why this is needed? This is update the profile counter after we do the promotion. |
Move zero value check into the tryPromoteAndInlineCandidate (cleaner and saves symbol look-up) . Meanwhile keep the check in updateIDTMetadata since it has two callers, and the other caller (generateMDProfMetadata) executes as long as the function is changed (e.g., by inliner without icp).
Done.
Yeah I realized doesHistoryAllowICP will return false, and updateIDTMetadata won't be executed within tryPromoteAndInlineCandidate.
There is another caller of updateIDTMetadata (https://github.com/llvm/llvm-project/blob/606cb8548a1b7763e0c8489c5efe66803a7ede72/llvm/lib/Transforms/IPO/SampleProfile.cpp#L1640), so keep the value check within updateIDTMetadata.
Why this is needed? This is update the profile counter after we do the promotion.
If the check works in doesHistoryAllowICP(), MaxNumPromptions here should not be 0, right?