Files
codeql/cpp/ql/test/library-tests
Dave Bartolomeo e27a0fe504 C++: Prevent AliasedVirtualVariable from overlapping string literals
We were hitting a combinatorial explosion in `hasDefinitionAtRank` for functions that contain a large number of string literals. The problem was that every `Chi` instruction for `AliasedVirtualVariable` was treated as a definition of every string literal. We already mark string literals as `isReadOnly()`, but we were allowing `AliasedVirtualVariable` to define read-only locations so that the `AliasedDefinition` instruction would provide the initial definition for all string literals.

To fix this, I've introduced the new `InitializeNonLocal` instruction, which is inserted in the prologue of every function right after `AliasedDefinition`. It provides the initial definition for every non-stack memory location, including read-only locations, but is never written to anywhere else. It is the conterpart of the `AliasedUse` instruction in the function epilogue, which represents the use of all non-stack memory after the function returns. I considered renaming `AliasedUse` to `ReturnNonLocal`, to match the `InitializeXXX`/`ReturnXXX` pattern we already use for parameters and indirections, but held off to avoid unnecessary churn. Any thoughts on whether I should make this name change?

This change has a significant speedup in evaluation time for a few of our troublesome databases:
`attnam/ivan`: 13%
`awslabs/s2n`: 26%
`SinaMostafanejad/OpenRDM`: 7%
`zcoinofficial/zcoin`: 8%
2020-01-31 11:33:46 -07:00
..
2019-12-03 09:00:43 +00:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2018-10-18 12:36:42 +01:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2018-10-26 11:07:18 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-05-02 11:16:21 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-11-07 14:08:25 +00:00
2020-01-20 15:00:09 +00:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2018-09-23 16:23:52 -07:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-22 14:08:05 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2018-09-23 16:24:31 -07:00
2019-11-13 18:53:43 +00:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2019-09-09 11:25:53 +02:00
2020-01-29 13:11:50 +01:00
2020-01-29 13:11:50 +01:00