On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther <richard.guent...@gmail.com> wrote:
> Yes. It won't handle > > if (x > 1) > ... > tem = x > 1; > > or > > if (x > 1) > ... > if (x > 1) > > though maybe we could teach PRE to do the insertion by properly > putting x > 1 into EXP_GEN in compute_avail (but not into AVAIL_OUT). > Not sure about this though. Currently we don't do anything to > GIMPLE_COND operands (which seems odd anyway, we should > at least add the operands to EXP_GEN). I did an experiment which shows by setting cond_expr in EXP_GEN properly, PRE could insert expression in following case: ---------------------------------------------------- //necessary declaration of variable a/b/g int tmp; if (x_cond) tmp = a > 2; else tmp = b; if (a > 2) g = tmp; But the problem you mention : "PRE separates conditional expression and jump to far" still exists in this kind of cases. Now I doubt the benefit to make PRE handle cond_expr, because in back end, machines normally have only one flag to store the result. And for other cases like: if (a > 2) ... if (a > 2) Current logic of insertion(in do_regular_insertion) simply won't insert expression before the first GIMPLE_COND statement, because it only considers basic blocks have multiple predecessors and the expression are partial redundant. Anyway I think this can be done by implementing new insertion strategy for GIMPLE_COND. -- Best Regards.
