Re: [tuples][patch] Don't create GIMPLE_CONDs that trap

["Rafael Espindola" <espindola at google dot com>]

>  Why did you need to change tree-complex.c?  I see you always build the
>  condition as tmp = comparison; if (tmp) but you don't split the BB before
>  the if if comparison traps (does stmt_ends_bb properly catch the trapping
>  comparison?)

I was getting verification errors saying that an invalid condexpr was
found. I tracked it being generated by tree-complex.c.

Are you saying that in tree-complex.c I should be generating:

tmp = comparison
goto foo;
foo:
if (tmp)

Will take a look into that. Why isn't the verifier catching it? What
should the error be? Something like "trapping instruction in the
middle of a BB"?

>  Similar for the tree-ssa-forwprop.c hunk - we don't preserve traps in general,
>  so the comment should be something like
>
>  /* If the rhs could trap, do not propagate from it as we do not handle splitting
>    blocks properly.  */
>
>  (which should match the reason you did change this here?)

No, it was reconstructing "if (a < b)" from "t = a < b; if (t)".

>  I guess we're be opening a can of worms with the change ;)  But it still
>  is correct.
>
>  The patch misses a ChangeLog btw.

Sorry, I am always too lazy to write one for "draft" patches. Will try
to get more used to the gcc way.

>  As of the testcase changes - can you open a missed optimization report?
>  I think both tree-ssa-phiopt.c and tree-if-conv.c do not properly deal with
>  split COND_EXPRs.

Will do.

>  Thanks,
>  Richard.


Thanks,
-- 
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047