Possible splitting of the nodes for better inlining handling?

[Melirius]

I'm always frustrated when I cannot extract obviously inlined function because some manipulations on its arguments just merge with the first node of it (and/or with the last node also). If it will be possible to split an existing node into several sequential nodes then the feature of inlined functions extraction will be much more useful - I can extract this merged parts, select only inlined function content and produce it.

Also splitting to produce an empty node at the end or the beginning of some node will be nice: I found out that if I have an inlined function nodes that flow into the same after-function node but on two different paths (so effectively the flow converges) plugin cannot extract it as an inlined function. An empty node extraction from this converging node will solve the problem (presumably it can help with folding too).

[srgblv]

I've been thinking about it. Yes it possible to manually split nodes and create inline from them. But I've no idea how to automatically split node of unknown code in advance at the same place as inline just before blocks matching.

Remind that inline is matched not as exact signature. Whole block instructions frequency dictionary is used for matching to be resistant to any kind of instructions reordering.

The only thing seems possible to improve: if the head node is two-ways block with if statement at the tail. So we can match only conditional jump as head block and cut off all above if. This will not solve problem in general just made some kind of inlines a bit accurate. And this non significant improvement will take considerable effort.

[Melirius]

Thank you for your answer. Indeed the problem you described makes the effort a bit too large for meaningful returns. However, the idea of node-splitting, if it can be realized with low effort, still attractive to me.

[srgblv]

Inline's node splitting is implemented in 128f397