Any value in pre-simplifying the DAG?

I've been adding some new flow statements to my compiler and realize the
easiest/laziest way to produce the DAG is just to store a flow variable
and end blocks with a "switch" branch. It appears the optimizers do a
fine job of unwinding the nonsense, reducing the conditions, and even
expanding the trailing paths.

For example, I terminate my blocks with a logical switch like this:
  switch return_path, next_block
    cleanup, except_block
    break, loop_block
    return, return_block
    rethrow, except_block

In most cases I'd say only 1-2 of the cases are actually possible
(return_path cannot be the other values). Is there any value in me
attempting to produce a cleaner DAG to pass to the optimizer, or would I
just be duplicating effort the passes will end up doing anyway?

Hi edA-qa mort-ora-y,

I've been adding some new flow statements to my compiler and realize the
easiest/laziest way to produce the DAG is just to store a flow variable
and end blocks with a "switch" branch. It appears the optimizers do a
fine job of unwinding the nonsense, reducing the conditions, and even
expanding the trailing paths.

For example, I terminate my blocks with a logical switch like this:
  switch return_path, next_block
    cleanup, except_block
    break, loop_block
    return, return_block
    rethrow, except_block

In most cases I'd say only 1-2 of the cases are actually possible
(return_path cannot be the other values). Is there any value in me
attempting to produce a cleaner DAG to pass to the optimizer, or would I
just be duplicating effort the passes will end up doing anyway?

does the front-end have special knowledge about the possible values? If the
front-end can do simplifications that the optimizers can't possibly do because
the required information can't be logically deduced from the IR, then the front
end will have to do it.

If the front-end can do the simplifications simply and cheaply, then it may be a
win to have the front-end do it, since significantly reducing the complexity of
the initial CFG may speed up LLVM's optimizers.

Otherwise, if LLVM is doing a good job, you might as well let it do the work.

Ciao, Duncan.

This is my primary concern now is speed. LLVM is doing a nicer job at
simplifying than I could, but I think the endless repetition of these
switches is likely slowing down the process. Most of the knowledge is
completely transparent thus there's nothing really more that I know at
the high level.

I'll do the really cheap things and cleanup what I can to reduce the
size, but otherwise I'll just let LLVM do the hard work. :wink: