Merging sequences of last-level statement blocks

[Matthias Boehm <mb...@googlemail.com>]

Hi all,

we see a lot of scripts where conditional statement blocks split DAGs of
operations. After constant folding of if predicates, unnecessary branches
are already removed (which is important for size propagation) but we don't
merge sequences of statement blocks yet. Consider the following example:

<block of operations 1>
if (intercept == 2) {
   <conditional block>
}
<block of operations 2>

If the script is invoked with intercept=0 or 1, the entire if block is
removed and we end up with a sequence of block 1 and block 2. This cut
unnecessarily hides optimization opportunities. I intend to add a rewrite
that merges such sequences under certain conditions.

Note that this renders the current debugging approach of explicit cuts via
"if(1==1){}" ineffective because we will anyway merge the resulting blocks.
You can use while(false) {} instead in the future.

Regards,
Matthias

Re: Merging sequences of last-level statement blocks

[Deron Eriksson <de...@gmail.com>]

Could we add a "cut()" or "cutGraph()" function to DML for debugging that
would cut the graph in a similar fashion as "if(1==1){}" and
"while(false){}"? It might be a little more straightforward and explicit
for users.

Deron

On Sun, Aug 6, 2017 at 3:42 PM, Matthias Boehm <mb...@googlemail.com>
wrote:

> Hi all,
>
> we see a lot of scripts where conditional statement blocks split DAGs of
> operations. After constant folding of if predicates, unnecessary branches
> are already removed (which is important for size propagation) but we don't
> merge sequences of statement blocks yet. Consider the following example:
>
> <block of operations 1>
> if (intercept == 2) {
>    <conditional block>
> }
> <block of operations 2>
>
> If the script is invoked with intercept=0 or 1, the entire if block is
> removed and we end up with a sequence of block 1 and block 2. This cut
> unnecessarily hides optimization opportunities. I intend to add a rewrite
> that merges such sequences under certain conditions.
>
> Note that this renders the current debugging approach of explicit cuts via
> "if(1==1){}" ineffective because we will anyway merge the resulting blocks.
> You can use while(false) {} instead in the future.
>
> Regards,
> Matthias
>