[PATCH][RFC] Force predicate computations to separate stmts

[PATCH][RFC] Force predicate computations to separate stmts

[Richard Guenther]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1050 bytes --]


This forces predicate computation in GIMPLE_CONDs and COND_EXPRs
into separate statements making GIMPLE_ASSIGNs the only place
where predicate computation happens.

This helps streamlining the code and allows for example value-numbering
to do sth with these predicates (and eventually drive jump-threading
from it).

The patch is largely mechanical (and after some mechanics some
helpers were invented but not retrofitted to earlier uses) - it is
a draft.  A load of testcase fails are expected because dumps
are different (as usual) and I simply disabled the most ugly
GIMPLE_COND code which is from auto-parallelization.

Other than that the patch bootstraps on x86_64-unknown-linux-gnu
for all languages without -Werror (I managed to partly disable
the new fancy uninitialized variable thing and so we get extra
warnings).

But - I'm fishing for comments (as usual) on this GIMPLE IL change.
(prominent examples where code simplifications were possible are
tree forwprop, VRP and DOM).

Richard.

(no changelog yet, bzipped attachment - it's big)

[-- Attachment #2: Type: APPLICATION/x-bzip, Size: 28193 bytes --]

Re: [PATCH][RFC] Force predicate computations to separate stmts

[Diego Novillo]

On 10-08-13 11:12 , Richard Guenther wrote:

> This helps streamlining the code and allows for example value-numbering
> to do sth with these predicates (and eventually drive jump-threading
> from it).

Nice!  This ought to help simplify VRP too.  We can move the assertions 
right after the assignments and remove the code that inserts assertions 
at the top of if-then-else blocks.

> But - I'm fishing for comments (as usual) on this GIMPLE IL change.

It's an obvious and useful cleanup.  Thanks.  I have not looked at the 
patch, but I presume that it's perfectly sensible and tedious.

Any changes in memory usage?


Diego.

Re: [PATCH][RFC] Force predicate computations to separate stmts

[Richard Guenther]

On Fri, 13 Aug 2010, Diego Novillo wrote:

> On 10-08-13 11:12 , Richard Guenther wrote:
> 
> > This helps streamlining the code and allows for example value-numbering
> > to do sth with these predicates (and eventually drive jump-threading
> > from it).
> 
> Nice!  This ought to help simplify VRP too.  We can move the assertions right
> after the assignments and remove the code that inserts assertions at the top
> of if-then-else blocks.

You still will have asserts 'on edges' - otherwise you don't know
if the predicate is true or false.

> > But - I'm fishing for comments (as usual) on this GIMPLE IL change.
> 
> It's an obvious and useful cleanup.  Thanks.  I have not looked at the patch,
> but I presume that it's perfectly sensible and tedious.

Heh.

> Any changes in memory usage?

I didn't yet measure memory usage or compile time (nor did I look at
all testcases that now fail).  But I would expect memory usage to
go up, not down (one gimple-assign compared to one less operand slot).

Oh, and as a followup a RHS COND_EXPR would now fit in GIMPLE_TERNARY_RHS.

Richard.

Re: [PATCH][RFC] Force predicate computations to separate stmts

[Michael Matz]

Hi,

On Fri, 13 Aug 2010, Diego Novillo wrote:

> On 10-08-13 11:12 , Richard Guenther wrote:
> 
> > This helps streamlining the code and allows for example value-numbering
> > to do sth with these predicates (and eventually drive jump-threading
> > from it).
> 
> Nice!  This ought to help simplify VRP too.  We can move the assertions 
> right after the assignments

Nope.  Computing a predicate doesn't imply taking a certain path:

bb1:
  code
  p1 = x < y;
  more-code;
  if (p1) goto bb3;
bb2:
  ...
bb3:

You really have associate the assertions with edges.


Ciao,
Michael.

Re: [PATCH][RFC] Force predicate computations to separate stmts

[Diego Novillo]

On Fri, Aug 13, 2010 at 11:35, Michael Matz <matz@suse.de> wrote:

> Nope.  Computing a predicate doesn't imply taking a certain path:

Yeah. brain fart, sorry.  I was thinking pointer indirection, but
computing the predicates says nothing about the resulting SSA.


Diego.