[llvm] [GlobalISel] Add iterative known-bits evaluation to GISelValueTracking (PR #221755)

[via llvm-commits]

daemonpilot wrote:

> Can we get some numbers on the performance impact of this patch? For example evaluating the transfer functions N times for `G_BUILD_VECTOR` of N elements will perform O(N^2) cache lookups which might regress performance.

Thanks for the sharp insight! You're right, for instructions like G_BUILD_VECTOR or PHI with N operands, the current iteration scheme would indeed degrade to O(N^2) due to repeated lookups.

The primary driver for switching from recursion to iteration here is to fix a stack overflow / compiler crash issue on deeply nested IR. To eliminate the O(N^2) bottleneck while keeping the stack-safe iterative approach, maybe we can solve this by storing the operand processing state (i.e., tracking the index of the last processed operand) on the iteration stack, bringing the complexity back down to O(N). Please let me know if you have any other suggestions or see further opportunities for optimization.

I will run llvm-compile-time-tracker to evaluate the actual compile-time impact. Thanks again for catching this!

https://github.com/llvm/llvm-project/pull/221755