C++ IR: guard against cycles in operand graph #1567
Conversation
This doesn't fix the underlying problem that for some reason there are cycles in the operand graph on our snapshots of the Linux kernel, but it ensures that the cycles don't lead to non-termination of `ConstantAnalysis` and `ValueNumbering`.
|
I have to add another commit to improve performance. See https://semmle.slack.com/archives/C20TR4EAZ/p1562678869029300 |
Without this `pragma[noopt]`, `isInCycle` gets compiled into RA that
unpacks every tuple of the fast TC:
0 ~0% {2} r1 = SELECT #Operand::getNonPhiOperandDef#3#ffPlus ON FIELDS #Operand::getNonPhiOperandDef#3#ffPlus.<0>=#Operand::getNonPhiOperandDef#3#ffPlus.<1>
0 ~0% {1} r2 = SCAN r1 OUTPUT FIELDS {r1.<0>}
return r2
With this change, it just becomes one lookup in the fast TC data
structure per instruction.
|
I've added a second commit to improve performance of the cycle detection. |
|
I've opened https://jira.semmle.com/browse/CPP-408 for the underlying issue. |
|
The cycle detection is unfortunately slow on Wireshark, taking between 1 and 2 minutes in each of the I haven't been able to speed it up on Wireshark. There seems to be a chain of tens of thousand memory operands somewhere. I've tried limiting the cycle detection to register operands, but there are no such cycles on Linux. I've tried finding all the non-cyclic operands via recursion through The cycle detection is perfectly fast on other snapshots I've tried, taking only 2 seconds on Linux. And it's certainly better to have slow cycle detection on Wireshark than to have infinite loops on Linux. |
This doesn't fix the underlying problem that for some reason there are cycles in the operand graph on our snapshots of the Linux kernel, but it ensures that the cycles don't lead to non-termination of
ConstantAnalysisandValueNumbering.