This commit removes potential UB in the PGO instrumentation passes that
was caused by casting away constness and then potentially modifying the
object.
Details
- Reviewers
xur gysit - Commits
- rGa4cc7e784f93: [PGO] Avoid potential const_cast UB (NFC)
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for working on this.
PGOEdge is shared by PGO instrumentation pass and PGO profile-use pass. We cast away const for PGO instrumentation. But for PGO profile-use, we don't change the BB. I would prefer to keep the const for profile-use passes. So I think a better fix is to make PGOEdge a template class, one with const and one without.
Added a comment to the critical UB causing part. Again, while there might be a way to keep constness, it requires extended changes. Fixing UB should be done first, afterwards, we can think about refactorings that allow us to keep constness where possible.
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp | ||
---|---|---|
817 | This full function is shared between the instrumentation and the use pass. Keeping const will always result in UB, as the SplitCriticalEdge function will be called with TI, which should be of type const Instruction *. I believe that splitting the logic between instrument and usage might help to reduce the complexity and push const in some places, but that requires extended changes to the algorithms. |
@xur how should we proceed with this. It seems like eliminating UB in favor of less constness seems like a good initial step?
This full function is shared between the instrumentation and the use pass. Keeping const will always result in UB, as the SplitCriticalEdge function will be called with TI, which should be of type const Instruction *.
I fail to see how a templated edge class would help in resolving this issue, could you elaborate @xur ?
I believe that splitting the logic between instrument and usage might help to reduce the complexity and push const in some places, but that requires extended changes to the algorithms.