[llvm-dev] [RFC] SimplifyCFG block speculation is a horribly inconsistent mess

[Krzysztof Parzyszek via llvm-dev]

On 11/15/2018 10:23 AM, John Brawn via llvm-dev wrote:
> 
>   * Any other ideas for how to make this less of a horrible mess?

My opinion is that we should rewrite it. And not the speculation part, 
but the whole thing.

The first problem is that there is really no clear description of that 
this pass does. "Simplify CFG" is a catch-all term that includes every 
little change that could be argued to simplify things in certain 
circumstances, and this has lead to what we have now. We should specify 
what the callers can expect to happen. "Expect the CFG to be simplified" 
is not an adequate specification. This is not a pass where we should be 
making frequent changes, since anything that happens here can have far 
reaching consequences.

There are certain types of CFG transformations that are needed more 
frequently, like folding a branch to a branch, or eliminating empty 
blocks (as long as it doesn't damage loop structure). At the same time, 
things like generating switch statements is not something that needs to 
be attempted every time. Subtypes of CFG optimizations should be 
identified (e.g. cleanups, aggressive branch elimination, etc.) and 
there should be a parameter by which the caller would indicate which of 
these optimization groups should be run.

The recursive algorithm is not the best choice here. For a graph like a 
CFG, the entire structure of it is important.  With the recursive nature 
of the code it can impossible to predict what it's going to do on any 
given graph, or determine why something predicted didn't actually 
happen. The algorithm should have a clear structure: first X happens, 
then Y, etc.

We should motivate the CFG simplification by what makes subsequent 
optimizations easier to implement and what exposes more opportunities to 
them, instead of "what helps my benchmark".  Maybe targets should have 
hooks to perform specific modifications of the graph that may or may not 
be good for everyone.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation