Add missing UnrolledLoopStatement to PGO region count calculator.
#3524
Conversation
tests/PGO/gh3375.d
Outdated
| @@ -0,0 +1,19 @@ | |||
| // REQUIRES: PGO_RT | |||
There was a problem hiding this comment.
Will this test get run with an LDC compiled with asserts enabled?
There was a problem hiding this comment.
@kinke do we have a CI system that runs with asserts enabled? I thought that the builds that output our latest-ci binaries do have asserts enabled, right?
There was a problem hiding this comment.
Yeah, Azure (excl. Android) and Shippable feature enabled assertions.
There was a problem hiding this comment.
With this addressed, all looks good to me.
| // If this assert fails, a new statement type was added to the frontend, and | ||
| // thus we need to decide on how to handle PGO calculations for that, both | ||
| // in MapRegionCounters and in ComputeRegionCounts. | ||
| assert(0 && "All statement types should be explicitly handled to avoid " |
There was a problem hiding this comment.
Does it make sense to do something in addition or other than assert so that detection is explicit in release mode builds that end users will use?
There was a problem hiding this comment.
I'm not sure. The error may not be user-actionable, and things may also just work without change needed. Would you suggest a warning saying that "Statement on line x is not supported by PGO" ?
There was a problem hiding this comment.
(note that this is the same for CaseRangeStatement)
There was a problem hiding this comment.
Would you suggest a warning saying that "Statement on line x is not supported by PGO" ?
Something like that. Perhaps requesting that an issue be filed for the purpose of improving LDC. This might make more sense if similar things are already being done elsewhere in the code base.
This rationale is that it might be difficult to catch these cases in the context of LDC development, and instead they'd be more likely to occur when running against user code. Do you think this is the case? If not, then such a message is not needed.
The other part is that PGO computation should proceed reasonably even if the assert condition arises. Ie. Not crash. I didn't try to review the code from this angle.
There was a problem hiding this comment.
Mind if I disregard this? We have many asserts in the codebase where we don't really report it to the user. (I think it is not very valuable for the user, to be honest) I do agree that the assert is not very likely to catch things during development, but it might when people use the beta build or latest-ci to have asserts enabled.
There was a problem hiding this comment.
Mind if I disregard this?
I don't mind. It was a suggestion for your consideration, nothing else. And it makes complete sense to be consistent with similar cases in the LDC code base.
|
|
…on and calculation. Also add extra precautions to catch this problem earlier in the future. Fixes issue #3375
JohanEngelen
force-pushed
the
pgocrashfix
branch
from
44ce5f3 to
65fa81a
Compare
|
I tested the PR on all the different reduced cases of bug #3375 I put together, the tool in |
|
I guess the Azure failure is a random error? Only |
Also adds extra precautions to catch this problem earlier in the future.
Fixes issue #3375