On Mon, Oct 12, 2020 at 02:39:24PM +0200, Martin Liška wrote:
> All right, I started to use init_range_entry in combination with
> linearize_expr_tree.
> One thing I have problem with is that linearize_expr_tree doesn't properly
> mark
> all statements as visited for cases like:
Not sure if linearize_expr_tree is what you want, then you run into many
reassoc dependencies (e.g. having computed uids and all that).
My suggestion was to just copy and tweak init_range_entry (and reuse the
fold_const range step stuff).
There is no need to linearize anything, for what you want it doesn't matter
if you process (x | y) | (z | w) where all of x, y, z, w are some
comparisons, or x | (y | (z | w)) etc. All you want to ensure is that
all the logical operations feeding each GIMPLE_COND are the same (all |s or
all &s), and that they make sense also for the basic blocks, then for each
of the subconditions find the ranges and verify that they all use the same
index. And then I think you shouldn't hoist anything either, rather check
that all the blocks but the first one are no_side_effect_bb (perhaps export
that one from reassoc), thus when you turn that into a switch starting at
the end of first bb, you can just throw away all the non-side-effects basic
blocks. Or do you want instead allow other stmts in those bbs and check
that either it is consumed all in the same bb, or it is consumed in the bbs
dominated by the bb that the case label for the particular case would be
added for, and sink the statements to that bb?
>
> <bb 4> :
> index2.1_1 = (unsigned int) index2_16(D);
> _2 = index2.1_1 + 4294967196;
> _3 = _2 <= 100;
> _5 = index2.1_1 + 4294966996;
> _6 = _5 <= 33;
> _7 = _3 | _6;
> if (_7 != 0)
> goto <bb 5>; [INV]
> else
> goto <bb 6>; [INV]
>
> As seen, all statements in this BB are used by the final _7 != 0 and it would
> be handy for me to identify all statements that should be hoisted.
>
> Thoughts how can I achieve that?
Jakub
