RFR: 8325144: C1: Optimize CriticalEdgeFinder

[Denghui Dong]

On Thu, 1 Feb 2024 16:49:02 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this change that removed the sorting process in split_edges by checking if the 'to' block has been substituted.
> 
> Thanks

The functionality of `CriticalEdgeFinder` is to insert a new block between the two blocks which satisfy the following conditions:

- the first block has at least 2 successors (the `from` block)
- the second block has at least 2 predecessors (the `to` block)
- the first is a predecessor of the second block

The flow of CriticalEdgeFinder:
1. collects all the block pairs whose `from` and `to` blocks satisfy the conditions above (`CriticalEdgeFinder::block_do`)
2. traverse the pairs to insert new blocks (`CriticalEdgeFinder::split_edges`)

In some cases (e.g. `LookupSwitch`), Several successors of a block can be the same. Hence, in `CriticalEdgeFinder::split_edges`, the pairs are sorted before handling them. And `last_pair` is used to check if a pair is handled already.

Since `BlockBegin::insert_block_between` replaces all matched successors with the new block and doesn't change the ordering or number of successors of the `from` block, we can check if the pair is handled by checking if the corresponding successor of the `from` block is changed. So we can remove the sorting process and simplify the code.

The only difference compared to the original result is that `_block_id` of new blocks changes. If I understand correctly, it doesn't influence subsequent compilation processes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17674#issuecomment-1936949639