This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, May 6, 2008 at 10:41 PM, Rafael Espindola <espindola@google.com> wrote:
> >  Please also fix this on the mainline (even though I realize that
>  >  tree_could_trap_p has diverged in tuples).
>
>  The attached patch does that. I had to add -fno-trapping-math to some
>  tests. I am not familiar with sse2, so I am not sure if this is a fix
>  or if I should open a PR for a missed optimization.
>
>  Bootstrapped and regression tested. Is it OK for trunk?

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?)

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?)

I guess we're be opening a can of worms with the change ;)  But it still
is correct.

The patch misses a ChangeLog btw.

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.

Thanks,
Richard.

>  >  Thanks,
>  >  Richard.
>
>
> >
>
>  Cheers,
>  --
>  Rafael Avila de Espindola
>
>  Google Ireland Ltd.
>  Gordon House
>  Barrow Street
>  Dublin 4
>  Ireland
>
>  Registered in Dublin, Ireland
>  Registration Number: 368047
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]